Key Concepts

XACML (eXtensible Access Control Markup Language) is a tool for controlling access to applications. XACML is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is very popular as a fine grained authorization method amongst the identity community. See Access Control Concepts for more information.

Role-based access control (RBAC) is a type of access control. It is an approach used to restrict access to authorized users based on their role. It is used by the majority of enterprises with more than 500 users. See Access Control Concepts for more information.

Attribute-based access control (ABAC) is a type of access control. ABAC defines a new access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. See Access Control Concepts for more information.

OAuth is an open standard to authorization. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections and access tokens. See OAuth Concepts for more information.

A token is a simple string that is passed as an HTTP header of a request. Access tokens authenticate API users and applications and ensure better security, e.g., preventing DoS attacks. If a token that is passed with a request is invalid, the request is discarded in the first stage of processing. WSO2 Identity Server supports following token types:

• Application access token: This token identifies and authenticates an entire application. You can invoke all the APIs associated with an application using a single application access token.

• User access token: This token identifies the end user of an application, e.g., the end user of a mobile application deployed on a different device.

• Refresh token: When an access token expires, you have to obtain a new access token to access the API. A refresh token enables to obtain a new access token without a user intervention and use it to regain access to the API.

• ID token: This is a JSON Web Token (JWT) containing the user's authentication status and profile information in the form of claims.

There are many supported grant types in the OAuth2 specification. A grant type is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. See OAuth Concepts for more information.

The responsibility of inbound authenticators is to identify and parse all the incoming authentication requests and then build the corresponding response. A given inbound authenticator has two parts.

1. Request Processor

2. Response Builder

For each protocol supported by WSO2 IS, there should be an inbound authenticator. This architecture component includes inbound authenticators for SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, and WS-Federation (passive). In other words, the responsibility of the SAML 2.0 request processor is to accept a SAML request from a service provider, validate the SAML request and then build a common object model understood by the authentication framework and handover the request to it. The responsibility of the SAML response builder is to accept a common object model from the authentication framework and build a SAML response out of it. Both the request processors and the response builders are protocol aware, while the authentication framework is not coupled to any protocol.

See Identity Server Architecture for more information.

The responsibility of the local authenticators is to authenticate the user with locally available credentials. This can be either username/password or even IWA (Integrated Windows Authentication). Local authenticators are decoupled from the Inbound Authenticators. Once the initial request is handed over to the authentication framework from an inbound authenticator, the authentication framework talks to the service provider configuration component to find the set of local authenticators registered with the service provider corresponding to the current authentication request.

Once the local authentication is successfully completed, the local authenticator will notify the framework. The framework will now decide no more authentication is needed and hand over the control to the corresponding response builder of the inbound authenticator.

You can develop your own local authenticators and plug them into the Identity Server.

See Identity Server Architecturefor more information.