Use Case scenarios with WSO2 Identity Server 5.0.0 - Part 1

Hi All,

Lets talk about few use case scenarios with new features of WSO2 IS 5.0.0 

1. Use Case 1 - SAML2 Web browser based SSO 

The above use case is explained in detail in the blog post SAML2 SSO with IS with a sample demo.

2. Use Case 2 – SAML2 Web Browse based SSO + Google authenticator + JIT Provisioning 

Lets try to understand the above scenario.

Lets think of this as an extended version of the use case 1 which would be an easy way to understand.

As I have explained in the post referred  in the use case 1, Web app acts as the SP and IS acts as the IdP. Now think that we want to be able to give access to the web app for the users who are not in the IS user store. These can be separate set of users say. How to tackle this with WSO2 IS server.

WSO2 IS can be set up with the OOTB feature of Google Authenticator for any user who has a Google email account to be logged into the web app. So how does that work?

1. User is trying to log into the web app and he is redirected to the IS login page.

2. Now there is an additional link that would be visible , therefore that as explained in the use case 1, the users who are in the user store of IS can login and also users who are not in user store of IS can also given the option to login using gmail account credentials.

3. Now when the user selects the link to be authenticated with google authenticator, he is redirected to the gmail login page. (Here, the google authenticator is is registered as a trusted IdP for the web application and the multiple login options are given for the webapp - please refer blog post at GoogleOpenId for an example setup)

4. The request that goes from the IS to the Gmail is an OpenIdConnect request and once the user is properly authenticated , an OpenIDConnect response come to the IS.

5. Now in order to be able to access the webbapp, this user must be created in the user store of IS, and this is done using Just In Time Provisioning which is enabled for the Google Authenticator. Therefore according to the response comes form the gmail , a user is created in the user store (one time user creation) with a default password.

6. And the user is given the access to the web application.

Use Case 3 – Multiple IdP federation

Now lets extend the use case 2 more to discuss more of multiple IdP federation features of IS 5.0.0.

Lets think about a scenario where there are no users exist in the IS1 user store for a particular web app, but the users of this web app can be authenticated using Gmail or IS2 IdP.

In the IS1, the Google Authenticator and IS2 can be registered as trusted IdP for IS1. And the webapp can be configured to trust the above 2 IdPs.

Therefore, some of the users can use Gmail for authentication and some can use IS2 for authentication, and some can use both.

There can be scenarios where, if the user is authenticated, he can access only some of the resources of the webapp and IS2 users some other resources depending on the authorization implementation logic of the webapp. 

See y'all!