How to configure a single sign-on system that assigns different authentication levels to different partner applications with OAM
Hi All,
After a one month gap I am writing blog and apologize for such a gap. Now I’m come back with good post. In this post I would like to explains how to configure a single sign-on system that assigns different authentication levels to different partner applications with OAM.
OracleAS Single Sign-On enables you to assign different authentication levels to the applications that it protects. You can then map these authentication levels to specific authentication plugins.
Environment Details:
Here, we have OAM 10g , two SSO servers(OID/OSSO 10g-10.1.4.3.0) and oracle portal 11g.
Integration details, Portal having own SSO server(OID/OSSO 10g-10.1.4.3.0) and portal application registered as a partner application in portal OSSO. Portal OSSO server is integrated with OAM for centralized authentication because in our project more than 10 application integrated with OAM10g(10.1.4.3.0) for SSO.
We are accessing all applications through Oracle Portal(11g) application by clicking links under portal workspace.
Employees, customers and agents applications are deployed in oracle portal 11g. All application will serve once OAM authentication successfully done because portal osso url’s are protected by OAM but our requirement is customer authentication alone bypass from OAM.
Solution is if application* would access the Portal site using a *different virtualhost*.
Implementation steps and issues:
- Oracle SSO 10g could be configured to implement a different authentication module for Customers accessing the Portal using the different hostname. Instead of using the OAM integration authentication module, OSSO would be able to use the default OSSO login module for native OSSO authentication.
- Of course the Customer virtualhost would not be protected by OAM, so the webgate would allow all requests for pages using that virtualhost through without redirection for OAM login.
Reference documentation for implementation of different OSSO authentication modules for different sites/virtualhosts:
Oracle Application Server Single Sign-On Administrator’s Guide 10g (10.1.4.0.1)
6 Multilevel Authentication
http://docs.oracle.com/cd/B28196_01/idmanage.1014/b15988/multilevel.htm
- Protect the portal application url’s using form based authentication in OAM.
/portal/pls/portal/PRT_PORTAL.wwsec_app_priv.login
/portal/pls/portal/PRT_PORTAL.wwpob_smd.login
2. Protect the Portal osso url’s using anonymous authentication in OAM.
/pls/orasso/orasso.wwsso_app_admin.ls_login
/sso/auth
Note: pass the header variables in both policy.
3. Customer virtualhost would not be protected by OAM so no need to specify url’s in OAM.
4. Implement OSSO Multilevel Authentication in OSSO policy.properties e.g.
empportal.domain\:7777 = HighSecurity
customerportal.domain\:7777 = MediumSecurity
HighSecurity_AuthPlugin = oblix.security.ssoplugin.SSOOblixAuth
MediumSecurity_AuthPlugin = oracle.security.sso.server.auth.SSOServerAuth
5. Restart osso server.
So the flow for Employees and Agents would now be:
a) User accesses Portal page http://empportal.domain:7777/portal/pls/portal -> the Portal public homepage is displayed.
b) User clicks on the Portal Login link in the homepage -> request for http://empportal.domain:7777/portal/pls/portal/PRT_PORTAL.wwsec_app_priv.login is issued
c) WebGate on Portal OHS finds that http://empportal.domain:7777/portal/pls/portal/PRT_PORTAL.wwsec_app_priv.login is protected -> user redirected to OAM login page
d) User submits valid credentials -> WebGate sets the ObSSOCookie for domain .eng.co.in and redirects back to http://empportal.domain:7777/portal/pls/portal/PRT_PORTAL.wwsec_app_priv.login
e) Portal receives the /portal/pls/portal/PRT_PORTAL.wwsec_app_priv.login request and checks for authenticated Portal session -> none exists so Portal redirects user to http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=…. for OSSO login
f) WebGate on OSSO OHS finds that http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login is protected by an anonymous policy so does not perform authentication because the existing ObSSOCookie has a higher authentication level than the anonymous authentication scheme. WebGate only performs authorization and sets the HTTP Header for OSSO-OAM integration on authorization success, to the user id obtained from the ObSSOCookie/OAM session token (not OblixAnonymous).
g) OSSO receives the http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login request and checks which partner application invoked the login request – it is found to be empportal.domain:7777 so the HighSecurity login module (SSOOblixAuth) is executed, which reads the HTTP Header for OAM-authenticated user identity and completes creation of the OSSO session.
h) OSSO redirects back to the Portal partner application login success URL at http://empportal.domain:7777/pls/portal/PRT_portal.wwsec_app_priv.process_signon
i) Portal processes OSSO login success and creates the Portal session cookie.
j) Portal redirects back to the default homepage for the authenticated user at at http://empportal.domain:7777/portal/pls/portal
The flow for Customers would be:
a) User accesses Portal page http://customerportal.domain:7777/portal/pls/portal -> the Portal public homepage is displayed.
b) User clicks on the Portal Login link in the homepage -> request for http://customerportal.domain:7777/portal/pls/portal/PORTAL.wwsec_app_priv.login is issued
c) WebGate on Portal OHS finds that http://customerportal.domain:7777/portal/pls/portal/PORTAL.wwsec_app_priv.login is NOT protected so allows the request through uninterrupted. No ObSSOCookie is set.
d) Portal receives the /portal/pls/portal/PORTAL.wwsec_app_priv.login request and checks for authenticated Portal session -> none exists so Portal redirects user to http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=…..for OSSO login
e) WebGate on OSSO OHS finds that http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login is protected by an anonymous policy so sets an OblixAnonymous ObSSOCookie in the session without prompting for OAM login. WebGate only performs authorization and sets the HTTP Header for OSSO-OAM integration on authorization success with value OblixAnonymous.
f) OSSO receives the http://sso.eng.co.in:7778/pls/orasso/orasso.wwsso_app_admin.ls_login request and checks which partner application invoked the login request – it is found to be customerportal.domain:7777 so the MediumSecurity login module (SSOServerAuth) is executed.
g) OSSO does not read the OSSO-OAM integration HTTP header because it is not relevant for the SSOServerAuth module. It checks for an existing SSO_ID cookie and finding none redirects the user to the default OSSO login page for login.
h) User submits valid credentials to OSSO.
i) OSSO processes the native authentication request and sets the OSSO SSO_ID cookie in the session.
j) OSSO redirects back to the Portal partner application login success URL at http://customerportal.domain:7777/pls/portal/portal.wwsec_app_priv.process_signon
k) Portal processes OSSO login success and creates the Portal session cookie.
l) Portal redirects back to the default homepage for the authenticated user at http://customerportal.domain:7777/portal/pls/portal
If you want to learn more in Oracle Access manager then register for our free Minicourse by clicking on below image.
About the Author sarath
An Oracle Identity and Access Management professional, having working on Oracle Access Manager Single Sign-On implementations, Installation/Configuration of Identity Server, Web Pass, Web Gate, Access Gate, Policy Manager, Access Server, Policy Domains, Authentication /Authorization schemes, Single Sign-On (single and multi-domain), OIM, OVD, OID, OAAM, OIF, High Availability/Failover/ SSL deployment.