Following diagram come out of a chat with Prabath, and it shows most of the public APIs of WSO2 Identity Server, and typical design and deployment choices with implementing authentication and authorization with WSO2 platform.
Each server in the WSO2 platform is built using the Carbon platform. We use the term “Carbon server” to denote any Carbon based server like ESB, AS, BPS.
Techniques explained here are applicable across most of the WSO2 products. In the following figure, and the circles with branching out paths shows different options.
As shown by the figure, Carbon server may receive two types of messages: messages with credentials (like passwords), and messages with tokens. When a server receives a message with credentials, the server first authenticates the request and optionally authorizes the action. When the server receives a message with tokens, generally there is no authentication step, and the token is directly validated against permissions and request is either granted or denied.
Carbon Servers support two user stores.
We can configure any Carbon server to authenticate any incoming requests. It supports many options like HTTP Basic Authentication over SSL for HTTP, WS-Security User Name Tokens, Web SAML SSO etc. This authentication is done against the users that reside the user store.
Also, each Carbon server has a Web Service called Authentication Admin Web Service, which exposes the authentication as a Web Service to the outside. The client can invoke the Authentication Admin Web Service and get a HTTP Cookie after logging in and reuse the Cookie to do authenticated calls to a Carbon Server.
Using XACML terminology, we can define three roles in such a scenario. (XACML includes other roles, which we will ignore on this discussion).
For Policy Definition Point (PDP), we support three ways to define permissions.
These gives rise to several scenarios
Authentication and Authorization Choices in WSO2 Platform |
Each server in the WSO2 platform is built using the Carbon platform. We use the term “Carbon server” to denote any Carbon based server like ESB, AS, BPS.
Techniques explained here are applicable across most of the WSO2 products. In the following figure, and the circles with branching out paths shows different options.
As shown by the figure, Carbon server may receive two types of messages: messages with credentials (like passwords), and messages with tokens. When a server receives a message with credentials, the server first authenticates the request and optionally authorizes the action. When the server receives a message with tokens, generally there is no authentication step, and the token is directly validated against permissions and request is either granted or denied.
Authentication
Authentication needs a User store that holds the information about users and “Enforcement Point” that verifies the credentials against the User store.Carbon Servers support two user stores.
- Database based user store
- LDAP based user store
We can configure any Carbon server to authenticate any incoming requests. It supports many options like HTTP Basic Authentication over SSL for HTTP, WS-Security User Name Tokens, Web SAML SSO etc. This authentication is done against the users that reside the user store.
Also, each Carbon server has a Web Service called Authentication Admin Web Service, which exposes the authentication as a Web Service to the outside. The client can invoke the Authentication Admin Web Service and get a HTTP Cookie after logging in and reuse the Cookie to do authenticated calls to a Carbon Server.
Authorization
In Authorization Scenarios, Carbon server receives a request that is generally already authenticated or a request that include a token. In either case, we want to check weather the authenticated user have enough permission to carry out a given action.Using XACML terminology, we can define three roles in such a scenario. (XACML includes other roles, which we will ignore on this discussion).
- PEP (Policy enforcement Point) intercepts requests and makes sure only authorized requests are allowed to proceed.
- PDP (Policy definition Point) stores the permissions and verify that given user have enough permissions
- PAP (Policy Administration Point) let users define and change permissions.
For Policy Definition Point (PDP), we support three ways to define permissions.
- Database based permission stores – permissions are stored in the Database
- XACML – permissions are described using XACML specification
- KDC - Permissions are provided as Kerberos Tokens
These gives rise to several scenarios
- If the Database based permission store is used, we can configure any Carbon Server to connect to the permission database directly and load the permissions to the memory. Then it authorizes user actions using those permission descriptions. Carbon servers also have an Authorization Admin Web Service that let users check for permissions of a given user remotely.
- If XACML based authorizations are used, there must be an Identity Server that acts as a PDP (Policy Definition Point). Each Carbon server (acting as the PEP, Policy Enforcement Point) invokes an Entitlement Service available in the Identity Server to check the permissions. Entitlement service is available as a Web Service or a Thrift Service.
- If Carbon server receives a Kerberos token, it talks to a configured Kerberos Server and verifies token. WSO2 IS come bundled with Apache KDC out of the box.
2 comments:
Site sites.google.com/a/wso2.com/sec…has lot of details about WSO2 platform security
So say I was staring from scratch, I was in the process of learning GlassFish because we want to implement an SOA. How do I make my Java EE containers use the WSO authentication and authorization services? Can you point me to some kind of document or examples on Stack Overflow?
Thanks!
Post a Comment