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)
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.
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.
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.
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.
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 ?
Yes. OAM 1Og will not support direct integration with portal application without OSSO. In later version we can integrated with portal directly without OSSO.
Great Post.This one not only clearly explains multilevel authentication in OSSO but also the authentication and authorisation flow between Portal–>OSSO–>OAM—>Portal.
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.
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?
