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:

  1. 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.
  2. 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

  1. 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.

OAM FREE Mini Course by Oracle ACE Atul Kumar

Series Navigation<< Your account is locked. You can unlock your account by going to Forgot PasswordSolution for OAM Error code OAM-02073 status fail is Excluded false >>
This entry is part 18 of 20 in the series Oracle Access Manager

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.

Leave a Comment:

6 comments
Atul Kumar says November 29, 2012

Good one Sarath. Just one query, Is there any reason for using 10g SSO (OSSO) as opposed to achieve this same functionality via Oracle Access Manager (OAM) ?

Is there any limitation on portal side that only OSSO must be used ?

Atul

Reply
sarath says November 30, 2012

Hi Atul,

Yes. OAM 1Og will not support direct integration with portal application without OSSO. In later version we can integrated with portal directly without OSSO.

Here, we are using OAM 10g.

-Sarath

Reply
Dinesh says December 4, 2012

Hello Sarath,

Great Post.This one not only clearly explains multilevel authentication in OSSO but also the authentication and authorisation flow between Portal–>OSSO–>OAM—>Portal.

Regards,
Dinesh.

Reply
sarath says December 4, 2012

Hi Dinesh,

My pleasure to explain :)

-Sarath

Reply
pamela says April 12, 2013

I loved as much as you will receive carried out right here.
The sketch is attractive, your authored subject matter stylish.
nonetheless, you command get bought an nervousness over that you wish be delivering the
following. unwell unquestionably come further formerly again since exactly the same nearly a lot often inside case you shield this hike.

Reply
Saurabh says February 25, 2015

Hi Sarath,

I am working in the same project which you worked in. Currently i am facing problem to implement the same. I have setup the exact same setup as you mentioned. But when i am authenticating eportal through OAM, it is going till step e) and after that authenticating oblixAnonymous user rather and throwing 401 unauthorized error. Can you please help with this?

Reply
Add Your Reply