IS 1
WSO2 IS Tutorial: Introduction

Index

Introduction

Parts in which the Identity Server is composed

Authenticators in the authentication framework:

Input Authenticators

Local Authenticators

Outgoing Authenticators/federated.

Provisioning Framework

Input Provisioning

Just-in-time provisioning

Provisioning Output.

The Service Provider (SP)

Authentication Framework.

Identity providers or external applications

Manager of authorizations.

User Store Manager

Claims Management

XACML

Audit

Identity Manager

Conclusion

Introduction

This is the first blog of the series dedicated to an exciting subject such as security and its management.
Specifically, we will use a brilliant tool such as the WSO2 Identity Server. We will start by studying what is
this tool and the parts of which it is composed.

The Identity Server is a server that manages securely identities such as employees, suppliers, partners,
customers, etc (anything that can be stored in a database as an entity has an identity) and access
between systems and applications with the possibility to use a single access and without the need to
repeat credentials every time a user needs to use a Service Provider.

As an identity manager and identity provider, it has a user and directory store, user authentication with
the 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 in which the Identity Server is composed

As shown in the diagram there are three distinct parts, the Identity Server (IS) and the local authenticators,
what they do is authenticate the user with local credentials. You can interpret the left part as the service
providers or Service Providers (SP) and the right as the federated identity providers or Identity Providers
(IdP) external to the IS.

This diagram throughout the series of blogs dedicated to the IS will be much clearer, and I advise you to
keep it as a reference. Now we go in parts.

Authenticators in the authentication framework

• Inbound Authenticators

These authenticators analyze the authentication request and construct the output response. These consist
of two parts, the Request Processor and the Response Generator. 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 over 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. Once the request is validated, it generates a Component
Object Model (COM) and sends it back together with the request to the Authentication Framework. The
Response Generator, in our example the SAML response builder, receives another COM object from the
Authentication Framework and generates a SAML response from that object. That response is sent to the
SP.

• 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 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 this according to the configuration it has can continue to send the request to

more types of authentication if it is configured in this way. At the end of the process this component sends

the response to the Response Builder of the Inbound authenticator.

• Outgoing / federated authenticators.

This component authenticates users through an Identity Provider (IdP) external to the IS, that's why it is

federated. The IdPs can be: Facebook, Google, Yahoo, LinkedIn, Twitter, SalesForce, Shibboleth, etc.

The authentication request reaches the Authenticator Framework. This query 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 by means of 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). This component constructs the authentication request according to the type of protocol
configured and sends it to the IdP. Later it processes the response and constructs another one 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:

I. Multi-optional Authenticators, where the SP has multiple options login.
II. Multi-factor authenticators, where the SP is configured to define several steps for authentication.

Provisioning framework

It is formed by the components:

• Inbound provisioning.

Input provisioning manages the registration of new users in the User Store. It can be done by means of
SOAP calls to the IS or with the Apis of the SCIM (System for Cross-domain Identity Management). The
inbound provisioning 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

This component does the same as the previous one, automatically registering users to the User Store.
But for those users who have successfully logged an external IdP. All this happens in the middle of the
authentication process.

• Outbound provisioning.

Manage the provision of users in external systems. All provisioning requests are initiated by an SP that
is associated with an IdP. And they are configured in the Outbound Provisioning section of the SP.

The Service Provider (SP)

It is not part of the IS but it must be configured in it. The Service Provider provides Web services. But you
need to somehow protect those services by means of an authentication and authorization. For this, it uses
the Identity Provider (IdP) of the IS or an external one if it is federated. A user tries to use a SP web service
to do this he tries to log in to the SP. The authentication request is sent from the SP to the IS. The 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 was registered in the SP, he can 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 interesting tasks of this component, in addition to the ones we have already mentioned, is claims
management. A claim is any type of information of the entity that is stored in the user store that is
exchanged between systems. As it 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 creates new users registered
in the SP, in the IS, on the flight. This component sends the request for registration to the Provisioning
Framework.

Identity providers or external applications

It is not a component of the IS but it is necessary to know it in order to configure it correctly in the IS. The
IdP perform authentication, the same as the internal IdP on the IS but through an external application such
as Facebook, Google, etc. The external 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 access control based on detailed policies through XACML. This
authorization management includes the editing 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. Also the IS through its UI facilitates the management of users through a series of menus
to create users, roles and profiles. The User Store Manager also receives requests for provisioning from
the Provisioning Framework. The User Store is then updated with a new user or modification. 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.
This receives the provisioning request, acts on it and sends it to the Provisioning Framework where it
must be sent to Outbound Provisioning.

Claims Manager

As I said, the claim stores information related to a subject or identity. Claims is a very common 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

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 in some way provide the necessary flexibility of a security tool such as the IS to be able
to expand with new security components and thus be able to respond to the current needs of companies.
It is also related to the User Store Manager.

Conclusion
This is the first installment of this series dedicated to WSO2 Identity Server. Do not worry if I do not explain everything in depth, I will do it in successive deliveries of this exciting topic of security and business

integrity at global level. The IS is the most complex and expensive tool of WSO2, among other things, it is
the one that must be up to date with possible security holes and constantly updated. It is a very valuable
tool that every company should have in its repertoire of business applications of security management. It is
very flexible and guarantees through interfaces the adaptability to the changing security logic of the
companies. In the next chapter we will enter fully into the IS website.