Welcome to the new section of the blog dedicated to Identity Server of WSO2, a revolutionary tool to ensure the security and correct identity management of any company. Whether you have already heard something about the tool, or not, this introductory post will help you to know it more deeply. You dare? We present the script for the first WSO2 Identity Server tutorial:
|
|---|
Introduction
As we mentioned at the beginning, we launched a new section in the blog dedicated to an exciting topic, such as business security and its management. For this, we will use a brilliant tool such as Identity Server (IS) of WSO2.
Before advancing in this solution, we must know very well what it is and what are the parts that compose it.
The Identity Server is a server that manages securely identities such as employees, suppliers, partners, customers, etc. (any type of information that can be stored in a database as an entity has an identity); and access between systems and applications, with the possibility of using a single access and without the need to repeat credentials every time a user needs to use a Service Provider.
As identity manager and identity provider, it has a directory and user store, authentication of the same with their corresponding name and password, or with the second factor method, user authorization to manage access permissions to certain resources once authenticated ; Single sign on, to log in once in an application and have access to other applications; provisioning, to be able to register users in the user store automatically, delegation of access or federated authentication, reset of access codes, auto registration in the manager, account locking and much more …
Parts that make up the Identity Server
As shown in the diagram there are three distinct parts, the Identity Server (IS) and the authenticators local, whose function is to authenticate the user with local credentials.
The left part could be interpreted as service providers or Service Providers (SP), and the right as the identity providers federated or Identity Providers (IdP) external to the IS.
Perhaps the diagram with so much information may seem a bit diffuse, but calm! Throughout the series of posts devoted to Identity Server (IS), you will be much brighter. Therefore, we advise you to always keep it in mind as a point of reference, or at least saved on your PC. Now it’s time to enter the subject, we go into parts:
Authenticators in the authentication framework
Input Authenticators
These authenticators analyze the authentication request input and build the output response. They are constituted by two parts, the Request Processor and the Response Generator (Request Processor, Response Builder).
This component is linked to different protocols depending on the authentication request protocol used by the Service Provider. That is, we have the protocol: SAML SSO, OAuth, Open ID Connect (built on the OAuth) and the Passive STS, as can be seen in the diagram.
For example, when the Request Processor receives an authentication request, it analyzes it to discover the authentication protocol used by the SP. If it is a SAML request, the request is redirected to the SAML 2.0 Request Processor. It validates the request and generates a Component Object Model (COM) and forwards it together with the request to the Authentication Framework.
The Response Generator, in our example the SAML response builder, receives another from the Authentication Framework COM and generates a SAML response from that object.
Local Authenticators
The responsibility of local authenticators is to authenticate the user with locally available credentials.
Authentication can be done with the username/password, with IWA (Integrated Windows Authentication) or through the request-path authenticator, where the credentials travel as part of the parameters in the request uri.
The request for authentication request is redirected from the incoming authenticators (Inbound Authenticators) to the Authenticator Framework. Now, this component communicates with a Service Provider configured in the IS to look for the local authenticators registered with the Service Provider corresponding to the authentication request.
When the authentication has completed successfully, the local authenticator notifies the Authenticator Framework and the Authenticator Framework, depending on the configuration it has, can continue to send the request or request to more types of authentication, if it is configured in this way. At the end of the process, this component sends the response or response to the Response Builder of the Inbound authenticator.
Outgoing / federated authenticators
This component authenticates the users using an Identity Provider (IdP) external to the IS, that is why it is federated.
The IdP can be Facebook, Google, Yahoo, LinkedIn, Twitter, SalesForce, Shibboleth, etc.
The authentication request reaches the Authenticator Framework. This one consults the configuration of the Service Provider. If there is any federated authentication configured, it forwards the request to the corresponding federated authenticator. This is already associated employing the SP configuration to an external IdP. The types of authentication protocols handled by this component are Security Assertion Markup Language (SAML) 2.0, OpenID Connect, Oauth 2.0 and WS-Federation (passive).
The Request Builder component will be responsible for building the authentication request according to the type of protocol configured and sending it to the IdP.
This same process later the response and build another directed to the Authenticator framework. The components that manage the request/response are Request Builder and Response Processor.
In both local and federated authentications, the SP can use two strategies:
- Multi-optional authenticators, where the SP has multiple login options.
- Multi-factor authenticators, where the SP is configured to define several authentication steps.
Supplying framework
The provisioning framework consists of the following components:
Input Provisioning
Provisioning Input provisioning manages the registration of new users in the User Store. It can be done utilizing SOAP calls to the IS or with the Apis of the SCIM (System for Cross-domain Identity Management).
The input provisioner is configured by associating it with a resident SP where the new User Store is indicated. Both APIs use HTTP Basic Authentication, and SCIM also uses Oauth protocol. The Oauth client id of the request is associated with the SP configured in the IS.
Just-in-time provisioning or just-in-time provisioning
This component does the same as the previous one, that is, automatically enlist users in the User Store, but for those users who have successfully logged in to an external IdP. You should know that all this happens in the middle of the authentication process.
Provisioning of output
Manages the provision of users in external systems. All provisioning requests are initiated by an SP that is associated with an IdP and are configured in the Outbound Provisioning section of the SP.
The Service Provider (SP)
Although it is not part of the IS, it must be configured in it.
The Service Provider is a service provider, that is, it provides Web services. But for this, you need to somehow protect those services through authentication and authorization. How do you do it? For easy it uses the Identity Provider (IdP) of the IS or an external one if it is federated. When a user tries to use an SP web service, he tries to log in to the SP.
The authentication request is sent from the SP to the IS. The incoming authenticator or Inbound authenticator receives the request that follows one of these formats: SAML SSP, Oauth / OpenID connect, Passive STS. This component sends the response to the authentication request to the SP, as positive or negative. Also, if the user registered in the SP, he/she will be able to send a request to the IS through the SOAP or SCIM protocol to the Inbound Provisioning component, to register the same user in the IS.
Authentication framework
Another of the exciting tasks of this component, in addition to the ones already mentioned, is in claims management.
A claim is any type of information of the entity that is stored in the user store that is exchanged between systems, which can be: email, telephone, name, surname, gender, etc. This information is mapped or related to the claims of the SP and the IdP.
The JIT component registers flight users registered in the SPy in the IS. This component sends the activation request to the Provisioning Framework or Provisioning Framework.
Identity providers or external applications
It is not a component of the IS but it is necessary to know it to be able to configure it correctly in the tool. The IdP perform authentication, the same as the IdP internal to the IS but through an external application such as Facebook, Google, etc.
The IdP also needs some type of configuration to enable the possibility of receiving authentication requests from the IS. The authentication protocols used here are: (SAML2, OpenID Connect, WS-Federation (Passive)). Another important fact is that a single authentication request may require authentication in more than one IdP.
Authorization manager
It provides rights management for any REST or SOAP call. This component is related to others such as XACML, WS-Trust, OpenID Connect and claims management for access control. It also provides role-based access control (RBAC) and detailed policies through XACML.
This authorization management includes the edition of security policies that include concepts such as the Policy Information Point (PIP) and Policy Decision Points (PDP).
User Store Manager
This component manages the persistence of users/roles and their profiles in the database.
This repository can be the internal LDAP of WSO2 (powered by ApacheDS), or an external LDAP, Microsoft Active Directory, or any JDBC database such as Mysql or Oracle.
Through a set of APIs, you can access the User Store.
The Identity Server through its UI facilitates the management of users thanks to a series of menus to create users, roles and profiles.
The User Manager also receives requests for provisioning from the Provisioning Framework.
The User Store is then updated with a new user or modification. You should know that this process can affect more than one User Store.
Finally, the response is sent to the Provisioning Framework. This component can also receive requests for provisioning from an SP through SOAP calls or with the SCIM protocol.
These requests go to Inbound Provisioning and from this to the User Store Manager.
The User Store Manager receives the provisioning request, acts on it and sends it to the Provisioning Framework, which in turn must be sent to Outbound Provisioning, Outbound Provisioning.
Claims Manager
As we mentioned, the claim stores information related to a subject or identity.
Claims are a prevalent way of transmitting identity data. This information can be packaged in tokens, such as SAML, issued by an issuer such as the Security Token Service (STS). This component is related to Authentication framework, Authorization manager, Provisioning framework and User store manager.
XACML
XACML or Extensible Access Control Markup Language (eXtensible Access Control Markup Language). It is a language to describe a fine-grained access control policy (who can do what and when) that is configured in an XML file and is standardized by OASIS (https://www.oasis-open.org).
The request/response language expresses queries about whether particular access (requests) should be allowed and describes the answers to those questions (answers).
Audit
Through this component, you can monitor privileged transactions processed by the system, access, authentication, performance and user sessions.
Identity Manager
This component will provide the necessary flexibility of a security tool such as the IS to be able to expand with new security components and thus be prepared to respond to the current needs of companies. It is also related to the User Store Manager.
Conclusion
As we said at the beginning, this is the first WSO2 Identity Server tutorial, very introductory, for beginners. Do not worry if everything was not explained in depth, because this will be all that we will do in the following IS publications. If after this post you find a very complete solution for business security and integrity globally, as you discover our following articles, it will still seem more so.
Before finalizing we would like to emphasize that the IS is the most complex and expensive tool of WSO2 since among other things it is the one that must always be up-to-date and up to date with possible security holes. Without a doubt, it is a precious solution that every company should have in its repertoire of security management business applications. Identity Server (IS) in addition to being very flexible, it is perfect to guarantee through interfaces the adaptability to the changing security logic of the companies.
Did you like our next tutorial dedicated to WSO2 Identity Server? If so, stay tuned for our next post in which we will enter fully on the Identity Server website.
Until next time!
Improve your IAM strategy, implementation and managed services, talk to our experts!
contact us about IAM
