SSO is the process of an application requesting for authentication credentials from an identity provider system. This type of systems will establish user identity for once and then share it across the sub systems.
Simply saying SSO systems allow users to log in once using a single id and a password and gain access to multiple systems without having to log into them individually.
There are different protocols used in SSO services such as Keberos and Security Assertion Markup Language (SAML). Here I have discussed how to do it using SAML 2.0. SAML is in XML standards. It facilitates exchanging user authentication data across secure domains.
There are three main components in SAML based SSO services.
- User
- Identity provider
- Service provider (Web application)
SSO process
- User tries to access the web application. It is deployed in WSO2 AS.
- Web application which acts as the service provider generates a SAML request.And there is a predefined SSO url in web application.
- It will then redirect the browser to SSO url with the encoded SAML request.
- Then browser will be redirected to SSO url which is going to be an instance of the identity provider created in WSO2 identity server.
- IS will then parse the SAML request. Check whether there is an already logged in user session. If not authenticate the user by asking their usernames and passwords
- IS will then generate the encoded SAML response which includes the username and user’s claims.
- Then it will redirect the browser to ACS with the generated SAML response.
- Browser will send the SAML response to ACS url. ACS url is the place where service provider receives assertions for the sent SAML requests.
- ACS will decode the SAML response and validate it. Then will decide whether to grant or deny access to that user.
- User will be granted or denied access to the web application.
No comments:
Post a Comment