Showing posts with label SSO. Show all posts
Showing posts with label SSO. Show all posts
Monday, November 2, 2015
Learning WSO2 Identity Server - MIND MAP
Labels:
fine-grained authorization,
IS,
metadata,
PIP,
SAML2 SSO,
SCIM. SPML,
SSO,
Tech Thoughts
Thursday, June 26, 2014
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!
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!
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
Thursday, August 1, 2013
How to set up Single Sign-On between different Carbon instances
Hello all, I am back :)
Today we are going to look into a use case scenario where SAML2 Single Sign-On is enabled between two carbon instances.
Note : In this blog post I am using two WSO2 IS 4.0.0 instances for the setup. One instance we consider as the Identity Provider, and the other instance is the Identity Relying Party.
First of all download the WSO2 IS, and copy the binary file into two separate folders(ex:- Identity Provider and Identity Relying Party) that you have created, and extract the content.
We need these two instances to run in two different ports.
Therefore, we need to select one of the instances and change the port. In order to do that go to the selected folder <productHome>\repository\conf and open the carbon.xml file.
Search for the <offset> tag and replace 0 with 1 to increment the default server running port by 1.
In this example I selected the Identity Relying Party, and changed the default port. Therefore it will run on port 9444.
Now , start a new command line window and run the Identity Provider. (You can refer the post How to Start Up WSO2 Identity Server for help)
Get the Identity Provider server running port from the command prompt, and go to Identity Relying Party <productHome>\repository\conf\security. Open the authenticators.xml file and set the following settings.
Priority : This should be grater than five to be picked up as the highest priority authenticator.
Parameter LoginPage : default login page url of carbon
Parameter ServiceProviderID: This is the unique identifier for the carbon server in an SSO setup, and this value should be used as the value of the issuer in the Identity Single Sign-On provider configurations.
Parameter IdentityProviderSSOServiceURL: This is the url of the Identity Provider and this should be in the following format https://(host-name):(port)/samlsso
Now go and open the management console of the Identity Provider on the browser window, and Login using admin, admin for username and password respectively.
Run the Identity Relying party server, opening another command prompt window, and get the server running port.
From the left menu panel of the Identity Provider, select Main and click on SAML SSO, and enter the following configurations.
Assertion Consumer URL should be in the format of https://(host-name):(port)/acs.
Now save the issuer, and log off from the management console of the Identity Provider.
Get the Identity Relying Party management console url and type it into your web browser.
Here you can see that you will be redirected to the Identity Provider with SAML2 SSO enabled, to enter the username and password.
Sign in using admin, admin as username and password respectively, and you will be redirected to your Identity Relying Party management console Home.
Thank you!
Today we are going to look into a use case scenario where SAML2 Single Sign-On is enabled between two carbon instances.
Note : In this blog post I am using two WSO2 IS 4.0.0 instances for the setup. One instance we consider as the Identity Provider, and the other instance is the Identity Relying Party.
First of all download the WSO2 IS, and copy the binary file into two separate folders(ex:- Identity Provider and Identity Relying Party) that you have created, and extract the content.
We need these two instances to run in two different ports.
Therefore, we need to select one of the instances and change the port. In order to do that go to the selected folder <productHome>\repository\conf and open the carbon.xml file.
Search for the <offset> tag and replace 0 with 1 to increment the default server running port by 1.
In this example I selected the Identity Relying Party, and changed the default port. Therefore it will run on port 9444.
Now , start a new command line window and run the Identity Provider. (You can refer the post How to Start Up WSO2 Identity Server for help)
Get the Identity Provider server running port from the command prompt, and go to Identity Relying Party <productHome>\repository\conf\security. Open the authenticators.xml file and set the following settings.
Parameter LoginPage : default login page url of carbon
Parameter ServiceProviderID: This is the unique identifier for the carbon server in an SSO setup, and this value should be used as the value of the issuer in the Identity Single Sign-On provider configurations.
Parameter IdentityProviderSSOServiceURL: This is the url of the Identity Provider and this should be in the following format https://(host-name):(port)/samlsso
Now go and open the management console of the Identity Provider on the browser window, and Login using admin, admin for username and password respectively.
Run the Identity Relying party server, opening another command prompt window, and get the server running port.
From the left menu panel of the Identity Provider, select Main and click on SAML SSO, and enter the following configurations.
Assertion Consumer URL should be in the format of https://(host-name):(port)/acs.
Now save the issuer, and log off from the management console of the Identity Provider.
Get the Identity Relying Party management console url and type it into your web browser.
Here you can see that you will be redirected to the Identity Provider with SAML2 SSO enabled, to enter the username and password.
Sign in using admin, admin as username and password respectively, and you will be redirected to your Identity Relying Party management console Home.
Thank you!
Labels:
How to,
Identity RP,
Identity Server,
IS,
SAML2 SSO,
SSO,
Tech Thoughts,
WSO2
Subscribe to:
Posts (Atom)












