• Find us:
    +1-669-900-5138   |   +44-203-372-5553
  • Free Newsletter

    Get Latest Updates

  • Make Training Enquiry


    Company

  • Categories

  • Archive

  • how to configure a single sign-on system that assigns different authentication levels to different partner applications with OAM

    Posted by "" in "10gAS, oam, sso, troubleshooting" on 2012-11-29

    Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

    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

     

     

    5 Responses to “how to configure a single sign-on system that assigns different authentication levels to different partner applications with OAM”

    1. Atul Kumar says:

      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

    2. sarath says:

      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

    3. Dinesh says:

      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.

    4. sarath says:

      Hi Dinesh,

      My pleasure to explain :)

      -Sarath

    5. pamela says:

      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.

    Leave a Reply



  • K21 Technologies is among the most experienced Oracle Gold Partner for Identity Access Management service providers. We work with application development companies and in-house technology division to help achieve significant returns on their IT security investment. Our clientele includes some of the globally renowned corporate, which speaks of our expertise in our field.

    We have the most talented and experienced team that can swiftly deploy security solutions even in complex IT ecosystem. Our clients highly appreciate our timely implementation, interactive training, on-demand support and community resources.
  • CONTACTS

    K21 Technologies
    8 Magnolia Place, Harrow,
    London, HA2 6DS

    UK: +44(0)7476444481
    USA: +1-888-414-1821

  • 2014, K21 Technologies. All rights reserved DMCA.com
  • TOP