Last modified by Admin User on 2025/01/16 14:24
From version 4.1
edited by Admin
on 2020/01/18 13:45
Change comment: There is no comment for this version
To version 3.1
edited by Admin
on 2020/01/18 13:44
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SSO Server: ONEcount SAML Server
1 +SAML Server
Content
... ... @@ -1,18 +1,18 @@
1 1  
2 2  
3 -{{id name="_GoBack"/}}
4 -SAML is setup on ONECount which can support both IDP and SP initiated logins. The main use of this saml is to provide authentication and authorization services for the SP while ONECount being IDP. We are using OPENSAML API to read the login requests and create SAML responses based on the authentication result. This document uses the following abbreviations.
5 -SP (Service Provider) : The system which is having the services the user requests for. The Service provider would just render services based on the authentication information provided by IDP.
6 -IDP (Identity Provider) : The system which manages the user details and the user privileges. The IDP would authenticate user and provide necessary information regarding the user to the SP.
7 -SAML: Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee. This defines the way SP and IDP communication protocols and how to react to requests.
8 -**SSO SERVICES:** In our ONECount we primarily use SAML for SSO Services across all the domains. The SSO services can be broadly divided into 2 types they are
3 +{{id name="_GoBack"/}}SAML Server
4 + SAML is setup on ONECount which can support both IDP and SP initiated logins. The main use of this saml is to provide authentication and authorization services for the SP while ONECount being IDP. We are using OPENSAML API to read the login requests and create SAML responses based on the authentication result. This document uses the following abbreviations.
5 + SP (Service Provider) : The system which is having the services the user requests for. The Service provider would just render services based on the authentication information provided by IDP.
6 + IDP (Identity Provider) : The system which manages the user details and the user privileges. The IDP would authenticate user and provide necessary information regarding the user to the SP.
7 + SAML: Security Assertion Markup Language is an XML-based, open-standard data format for exchanging authentication and authorization data between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee. This defines the way SP and IDP communication protocols and how to react to requests.
8 + **SSO SERVICES:** In our ONECount we primarily use SAML for SSO Services across all the domains. The SSO services can be broadly divided into 2 types they are
9 9  
10 10  * SP Initiated login
11 11  * IDP Initiated Login
12 12  
13 13  **SP Initiated login:** In this type of login the service provider requests for authentication to the IDP on for the same site. In our setup the example for this is harbourside MEDED website login. In SP initiated login the SP needs to create SAML request and send into to ONECount. The onecount then authenticates the user and sends the required details to the SP back as SAML response.
14 -**IDP Initiated login:** In this type of login the request for authentication would be by made by a partner site or third party site other than SP. In our setup the example is for ethos where the harbourside acts as partner site and has link to ethos websites where we authenticate the user and send required information to SP which is ETHOS in this context. In this type login is initiated by IDP to the SP.
15 -**DataBase models:** we have 2 tables in onecount_super data base as these configurations are common for all the clients. WE populate these tables based on the saml meta data file of service provider and other configurations. The table names are
14 + **IDP Initiated login:** In this type of login the request for authentication would be by made by a partner site or third party site other than SP. In our setup the example is for ethos where the harbourside acts as partner site and has link to ethos websites where we authenticate the user and send required information to SP which is ETHOS in this context. In this type login is initiated by IDP to the SP.
15 + **DataBase models:** we have 2 tables in onecount_super data base as these configurations are common for all the clients. WE populate these tables based on the saml meta data file of service provider and other configurations. The table names are
16 16  
17 17  {{id name="OLE_LINK2"/}}
18 18  
... ... @@ -23,9 +23,8 @@
23 23  {{id name="OLE_LINK5"/}}
24 24  
25 25  {{id name="OLE_LINK6"/}} onecount_saml_relaystate_mapping and their structure is as follows.
26 -onecount_saml_metadata
26 + onecount_saml_metadata
27 27  
28 -(% class="wrapped" %)
29 29  |=(((
30 30  **Column**
31 31  )))|=(((
... ... @@ -38,13 +38,10 @@
38 38  )))|(((
39 39  varchar(400)
40 40  )))|(((
41 -(% class="content-wrapper" %)
42 -(((
43 43  
44 44  
45 45  {{id name="OLE_LINK1"/}}The entity id of SP which we get in SAML Metadata file.
46 46  )))
47 -)))
48 48  |(((
49 49  soap_binding
50 50  )))|(((
... ... @@ -146,9 +146,8 @@
146 146  )))
147 147  
148 148  
149 -onecount_saml_relaystate_mapping
145 +onecount_saml_relaystate_mapping\\
150 150  
151 -(% class="wrapped" %)
152 152  |=(((
153 153  **Column**
154 154  )))|=(((
... ... @@ -194,11 +194,11 @@
194 194  * Login Response
195 195  
196 196  Login Request: The login request needs to be a valid saml request.
197 -SP intitiated login: In the case of the SP initiated login ONECount supports Post request with the request payload. We read the request by opensaml java api and extract the required parameters for authentication.
198 -IDP Initiated login: In the case of IDP initiated login the partner site needs to have the relay state which is the url of the SP that they want to user to access. They also need to add a query parameter clientid which is used by the onecount to correctly identify the client- SP pair.
199 -Login Mechanism:
192 + SP intitiated login: In the case of the SP initiated login ONECount supports Post request with the request payload. We read the request by opensaml java api and extract the required parameters for authentication.
193 + IDP Initiated login: In the case of IDP initiated login the partner site needs to have the relay state which is the url of the SP that they want to user to access. They also need to add a query parameter clientid which is used by the onecount to correctly identify the client- SP pair.
194 + Login Mechanism:
200 200  The SAML Server relies on cookies for user identification. When the saml receives the login request that looks up the configuration form the database based on entity ID if its SP initiated or relay state and clientid. Then that checks for OCGT cookie. If the cookie is found then that searches the onecount_super database for the ocid of the user form OC_CLIENTS_TOKENS table based on the client id and ocgt value. If an entry is found that means that we are able to identify the user based on the oc_gt cookie.
201 -If the cookie is not found or the user could not be identified based on oc_gt and clientid then the server is unable to accurately identify the user then the saml redirects the user to login/lookup page for further authentication.while redirectiong the user the whole url of partner site is URLENCODED and sent as return parameter to login/lookup page. When the user authenticates himself the login server sets the updated cookie for the user which is taken and searched in the database.
196 + If the cookie is not found or the user could not be identified based on oc_gt and clientid then the server is unable to accurately identify the user then the saml redirects the user to login/lookup page for further authentication.while redirectiong the user the whole url of partner site is URLENCODED and sent as return parameter to login/lookup page. When the user authenticates himself the login server sets the updated cookie for the user which is taken and searched in the database.
202 202  When the user is found the server makes a call to ONECount API to retrieve the user information. Once the user information is acquired the saml request is generated.
203 -SAML Response:
204 -The response is generated based on the configuration files using opensaml API. If that is SP initiated login then we have the extra parameter "InResponseTo" in the response which will have the unique request identifier which is used by the service provider to determine their internal state. In the request if the server receives any relay state then SAML server retains that and forwards the relay state without any modification. If it is IDP initiated login then the server will have the SP requested url as the relay state. In our setup we are using URL post binding to send the response to the SP.
198 + SAML Response:
199 +The response is generated based on the configuration files using opensaml API. If that is SP initiated login then we have the extra parameter "InResponseTo" in the response which will have the unique request identifier which is used by the service provider to determine their internal state. In the request if the server receives any relay state then SAML server retains that and forwards the relay state without any modification. If it is IDP initiated login then the server will have the SP requested url as the relay state. In our setup we are using URL post binding to send the response to the SP.\\
Confluence.Code.ConfluencePageClass[0]
id
... ... @@ -1,1 +1,1 @@
1 -23331755
1 +23331751
url
... ... @@ -1,1 +1,1 @@
1 -https://info.onecount.net//wiki/spaces/OD/pages/23331755/SSO Server: ONEcount SAML Server
1 +https://info.onecount.net//wiki/spaces/OD/pages/23331751/SAML Server