This post talks about the architecture, integration aspects and troubleshooting tips for the SSO implementation between WLS and WLP applications.
Architecture:
Description:
The components present in this architecture are Oracle Access Manager 10.1.4.3, Weblogic Server 10.3.0 and Weblogic Portal 10.3.0, SSPI Connector 10.1.4.2.2 and OHS webserver 11g .
The objective is to get Single Sign-On between Weblogic server and weblogic portal resources using SSPI connector.
Two SSPI connectors are used for Weblogic Server and Portal acting in Identity Assertion Provider mode which is available by default configuration. The OHS webserver acting as reverse proxy for both Weblogic Server and portal applications.
Here, the authentication & authz for Weblogic server resource happens through Oracle Access Manager using SSPI connector. However for the Weblogic Portal, only the authentication happens through OAM and Authz happens via Weblogic Portal.
The flow is described as shown below for Single Sign-On when user traverse from WLS to WLP applications:
1. User access Weblogic Server application through Proxy server and it is intercepted by OHS Webgate and checks with Policy Manager if the resource is protected or not.
2. If resource is protected, Webgate challenges user with form login. Form scheme is recommended for SSO solutions.
3. Login details are validated by Access Server and upon successful authentication, it checks if user is authorized to access the resource.
4. If user is authorized to access then Access server creates cookie and passes it to the browser.
5. The mod_proxy plugin present in the OHS server forwards the request to the Weblogic Server.
5. The Weblogic Security Framework invokes the SSPI connector and Identity Assertion provider listens for ObSSOCookie.
6. IAP will then check the user identity taken from the ObSSOCookie with the weblogic.
7. Upon successful verification, requested resource is shown.
8. User will then access the WLP portal application through the reverse proxy server.
Note: The WLP application is not protected by the OAM where as WLS application is protected by OAM.
9. The OHS webgate checks for the presence of cookie in the user session.
10. The ObLoginFilter configured in the web.xml gets invoked and checks for the ObSSOCookie. If its not present then it will present ObLogin.jsp. Since cookie is present in this scenario, it will check with the weblogic if the user is authorized to access the portal.
11. Upon successful authz, portal will be shown.
The flow is described as shown below for Single Sign-On when user traverse from WLP to WLS applications:
1. User access Weblogic portal application through Proxy server and it is intercepted by OHS Webgate and checks with Policy Manager if the resource is protected or not.
2. Since the user session does not have ObSSOCookie present, then ObLogin.jsp will be shown to enter login details.
3. Login details are validated by ASDK against Access Server and generates ObSSOCookie programatically.
4. It also checks against Weblogic if user is authorised to access the portal.
5. If user is authorized then portal page will be shown.
6.The user will then access the WLS application through the reverse proxy.
7. The OHS webgate intercepts request and check for cookie.
8. Since cookie is present, the mod_proxy plugin in OHS will forward request to Weblogic Server.
9. The Weblogic Security Framework invokes the SSPI connector and Identity Assertion provider listens for ObSSOCookie.
10. IAP will then check the user identity taken from the ObSSOCookie with the weblogic.
11. Upon successful verification, requested resource is shown.
Troubleshooting Tips:
1. Ensure that IPValidation for OHS webgate and both Access gates (portal and server) are OFF. Otherwise when user access WLS resource it will prompt for authentication.
2. Ensure that Login filter mappings are added in the portal application web.xml as shown below.
OblixLoginFilter
com.oracle.login.ObLoginFilter
OblixLoginFilter
/portlets/login_validate/*
web.xml
Architecture:
Description:
The components present in this architecture are Oracle Access Manager 10.1.4.3, Weblogic Server 10.3.0 and Weblogic Portal 10.3.0, SSPI Connector 10.1.4.2.2 and OHS webserver 11g .
The objective is to get Single Sign-On between Weblogic server and weblogic portal resources using SSPI connector.
Two SSPI connectors are used for Weblogic Server and Portal acting in Identity Assertion Provider mode which is available by default configuration. The OHS webserver acting as reverse proxy for both Weblogic Server and portal applications.
Here, the authentication & authz for Weblogic server resource happens through Oracle Access Manager using SSPI connector. However for the Weblogic Portal, only the authentication happens through OAM and Authz happens via Weblogic Portal.
The flow is described as shown below for Single Sign-On when user traverse from WLS to WLP applications:
1. User access Weblogic Server application through Proxy server and it is intercepted by OHS Webgate and checks with Policy Manager if the resource is protected or not.
2. If resource is protected, Webgate challenges user with form login. Form scheme is recommended for SSO solutions.
3. Login details are validated by Access Server and upon successful authentication, it checks if user is authorized to access the resource.
4. If user is authorized to access then Access server creates cookie and passes it to the browser.
5. The mod_proxy plugin present in the OHS server forwards the request to the Weblogic Server.
5. The Weblogic Security Framework invokes the SSPI connector and Identity Assertion provider listens for ObSSOCookie.
6. IAP will then check the user identity taken from the ObSSOCookie with the weblogic.
7. Upon successful verification, requested resource is shown.
8. User will then access the WLP portal application through the reverse proxy server.
Note: The WLP application is not protected by the OAM where as WLS application is protected by OAM.
9. The OHS webgate checks for the presence of cookie in the user session.
10. The ObLoginFilter configured in the web.xml gets invoked and checks for the ObSSOCookie. If its not present then it will present ObLogin.jsp. Since cookie is present in this scenario, it will check with the weblogic if the user is authorized to access the portal.
11. Upon successful authz, portal will be shown.
The flow is described as shown below for Single Sign-On when user traverse from WLP to WLS applications:
1. User access Weblogic portal application through Proxy server and it is intercepted by OHS Webgate and checks with Policy Manager if the resource is protected or not.
2. Since the user session does not have ObSSOCookie present, then ObLogin.jsp will be shown to enter login details.
3. Login details are validated by ASDK against Access Server and generates ObSSOCookie programatically.
4. It also checks against Weblogic if user is authorised to access the portal.
5. If user is authorized then portal page will be shown.
6.The user will then access the WLS application through the reverse proxy.
7. The OHS webgate intercepts request and check for cookie.
8. Since cookie is present, the mod_proxy plugin in OHS will forward request to Weblogic Server.
9. The Weblogic Security Framework invokes the SSPI connector and Identity Assertion provider listens for ObSSOCookie.
10. IAP will then check the user identity taken from the ObSSOCookie with the weblogic.
11. Upon successful verification, requested resource is shown.
Troubleshooting Tips:
1. Ensure that IPValidation for OHS webgate and both Access gates (portal and server) are OFF. Otherwise when user access WLS resource it will prompt for authentication.
2. Ensure that Login filter mappings are added in the portal application web.xml as shown below.
web.xml
Hi Mahendra,
ReplyDeleteCan you repost this article or find the architecture diagram.
Thanks
Hello,
ReplyDeleteThis diagram shown here http://download.oracle.com/docs/cd/E12530_01/oam.1014/e10356/img/aiing003.gif applies.
Please let me know if you need any more information.
-Mahendra.
Hi ,
ReplyDeleteI'm trying to integrate Ping Federate in our WLP 10.3.
Portal has existing Authentication.Login mechanism taking username/password from form coming from JPF controller and then userProfile is created using username.
But now there would Ping Federate server talking to OAM and do authentication and just pass openToken to our application URL and we will read parameters from openToken like username but password will not be available and now how will we move ahead with current Authentication.login as it ask for password of user and only then creates user profile, but we dont have password and if we authentication then this is two way authentication once OAM and then portal authentication and profile creation.
Hi Atul,
ReplyDeleteI'm trying to integrate Ping Federate in our WLP 10.3.
Portal has existing Authentication.Login mechanism taking username/password from form coming from JPF controller and then userProfile is created using username.
But now there would Ping Federate server talking to OAM and do authentication and just pass openToken to our application URL and we will read parameters from openToken like username but password will not be available and now how will we move ahead with current Authentication.login as it ask for password of user and only then creates user profile, but we dont have password and if we authentication then this is two way authentication once OAM and then portal authentication and profile creation.