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!
Thursday, June 26, 2014
Use Case scenarios with WSO2 Identity Server 5.0.0 - Part 1
Labels:
Identity Server,
IS,
SAML2 SSO,
SSO,
Tech Thoughts
SAML2 SSO with IS 5.0.0
Lets talk about the simple saml2 sso scenario with WSO2 IS 5.0.0 today.
Simple understanding of the concept can be grabbed with the following diagram.
WSO2 IS provides SAML2 Web browser based SSO acting as IdP or SP. In the above scenario the web app is the service provider and the IS is the identity provider. There is a pre defined trust relationship built between SP and the IdP when enabling SAML2 SSO.
How the above scenario works :-
1. The web app is registered as trusted SP in IS
2. Web app implements the saml2 sso and talks to IS using the assertion consumer url defined
NOTE :- If the authentication request / response signature validation is needed the proper importing / exporting of certificate to the trust-stores are needed.
USE CASE SCENARIO
----------------------------------
1. User comes and tries to log into the web app
2. SAML2 Web browser based SSO is configured for the web app with WSO2 IS
3. User is redirected to the IS login page
4. User enters the login credentials
5. If the user exist in the user store of the trusted IdP (IS) user is allowed to log into the web app
DEMO
---------
Lets check on how to quickly demo this using an example app and WSO2 IS.
Required :-
1. Please download the IS 5.0.0. for the product page.
2. Checkout the following sample travelocity app and build using maven
Configurations
--------------------
1. Take the .war file of the web app and deploy it on the tomcat server (version 7)
2. Startup WSO2 IS
3. Now lets register the SP in the IS
A. Go to management console main - > Service Providers -> Add
B. Give an unique name for the SP and click on register
C. Then click on the Inbound Authentication Configuration -> Configure
D. Fill on the details as follows :-
NOTE:- you can change these properties accordingly as expected by the SP. The properties for the webapp can be found at apache-tomcat-7.0.42\webapps\travelocity.com\WEB-INF\classes\travelocity.properties file
The filled in infor in the above example as follows :-
Issuer :- travelocity.com
Assertion Consumer URL :- http://localhost:8080/travelocity.com/home.jsp
User fully qualified username in the NameID :- TRUE
Enable SLO :- TRUE
Once configured click on update on the SAML2 config page as well as the SP information page that comes next. And you are good to go.
Now paste the following url on the browser http://localhost:8080/travelocity.com/index.jsp
and click on SAML login where you will be redirected to IS login page. When you enter admin, admin (the default super user of IS) TADA you are in :)
BYE BYE for now ;)
Simple understanding of the concept can be grabbed with the following diagram.
WSO2 IS provides SAML2 Web browser based SSO acting as IdP or SP. In the above scenario the web app is the service provider and the IS is the identity provider. There is a pre defined trust relationship built between SP and the IdP when enabling SAML2 SSO.
How the above scenario works :-
1. The web app is registered as trusted SP in IS
2. Web app implements the saml2 sso and talks to IS using the assertion consumer url defined
NOTE :- If the authentication request / response signature validation is needed the proper importing / exporting of certificate to the trust-stores are needed.
USE CASE SCENARIO
----------------------------------
1. User comes and tries to log into the web app
2. SAML2 Web browser based SSO is configured for the web app with WSO2 IS
3. User is redirected to the IS login page
4. User enters the login credentials
5. If the user exist in the user store of the trusted IdP (IS) user is allowed to log into the web app
DEMO
---------
Lets check on how to quickly demo this using an example app and WSO2 IS.
Required :-
1. Please download the IS 5.0.0. for the product page.
2. Checkout the following sample travelocity app and build using maven
Configurations
--------------------
1. Take the .war file of the web app and deploy it on the tomcat server (version 7)
2. Startup WSO2 IS
3. Now lets register the SP in the IS
A. Go to management console main - > Service Providers -> Add
B. Give an unique name for the SP and click on register
C. Then click on the Inbound Authentication Configuration -> Configure
D. Fill on the details as follows :-
NOTE:- you can change these properties accordingly as expected by the SP. The properties for the webapp can be found at apache-tomcat-7.0.42\webapps\travelocity.com\WEB-INF\classes\travelocity.properties file
The filled in infor in the above example as follows :-
Issuer :- travelocity.com
Assertion Consumer URL :- http://localhost:8080/travelocity.com/home.jsp
User fully qualified username in the NameID :- TRUE
Enable SLO :- TRUE
Once configured click on update on the SAML2 config page as well as the SP information page that comes next. And you are good to go.
Now paste the following url on the browser http://localhost:8080/travelocity.com/index.jsp
and click on SAML login where you will be redirected to IS login page. When you enter admin, admin (the default super user of IS) TADA you are in :)
BYE BYE for now ;)
Labels:
Identity Server,
IS,
SAML2 SSO,
SSO,
Tech Thoughts
Subscribe to:
Posts (Atom)