In my web application, need to use the siteminder implement the SSO with websphere liberty profile. But how to configure the liberty profile and siteminder and let them work smoothly? Hope your tips. Thanks.
WebSphere Liberty profile supports the Trust Association Interceptor (TAI) plug-point (similar to the full profile WebSphere) that a SiteMinder provided TAI implementation can be used to integrate with for SSO.
You can search for SiteMinder and WebSphere to get more information about their TAI implementation and integration with full profile. Configuration of TAI in the liberty profile is described here
Related
Please share the steps for Websphere integration with IDP providers. Like Okta, Microsoft e.t.c
I am configuring Okta getting an issue. If any one have done. Can they help me.
I'm assuming you're using Liberty app server, this video may help
If you're using traditional WebSphere, use these two documents:
Enabling SAML Web SSO
Configuring SSO Partners
Following those two step-by-step documents will configure IdP-initiated SAML Web SSO using OKTA as the IdP.
We are trying to configure a Liberty Server to host and render custom JSR286 portlets to IBM Portal via WSRP. The Default Server configuration for features and LDAP, LTPA and SSO is done and two IBM WSRP 2.0 Producer EAR files have been deployed. One is configured for NO security and the other have been configured for WS-Security by setting the Environment Variables in the web.xml files respectively.
On the portal server we can get the portlets consumed from the non-secured producer, and have configured HTTP LTPA cookie forwarding for the secured producer.
When trying to consume a portlet from the secured producer, I can see the LTPA cookie in die SOAP headers, but we are getting "MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood"
I followed the WSRP Documentation on how to configure security for WSRP for Websphere Liberty by using HTTP-cookie-based sso : See section "Securing the WSRP Producer by HTTP-cookie-based single sign-on" in WSRP Documentation
Following this info, I still get the "MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood" error in the logs.
All I need at the end of the day, is a secure way to use the WSRP producer (Downloaded from IBM WSRP 2.0 Producer) on Liberty profile to expose portlets to IBM WebSphere Portal and exchange the user context for the portlets to be able to get the logged in user details.
How do one configure security for WSRP for WebSphere Liberty?
NOTE: Not Full profile, but for Liberty profile.
Can somebody please help or point us in the right direction
have you done the steps to share the ltpa keys and set both consumer and producer to the same user registry
The doc states this "The requirements for SSO depend on the authentication method that is used. For example, if you use LTPA version 1 or version 2, the WSRP Consumer and the WSRP Producer must use the same user registry or use the same realm. In addition, the WSRP Producer and the WSRP Consumer must exchange shared keys that are used to sign the security credentials."
per here https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/wsrpt_prod_sec_ws.html
I would test that SSO is working by itself before trying to even bring wsrp into the mix
and more steps to configure on the consumer https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/wsrpt_cons_sec_ws_http_cb_sso.html
I have been trying to use the CAS Authentication for a Websphere Portal 8.0.1 application. Followed a few links :
https://wiki.jasig.org/pages/viewpage.action?pageId=19314
https://portalplus.wordpress.com/2012/04/10/configure-websphere-portal-with-cas-sso/
This help was mainly in pursuit of finding a ready-made Trust Association Interceptor (TAI) and a possible login modules if needed.
But looks like Portal CASsification is not a well known territory. I did all the configurations , but looks like TAI is not calling CAS serviceValidation URL, so even when I am redirected to portal application , the session is not authenticated, So I see blank portlets.
So I am stuck at a few points :
Apart from Yale provided TAI , is there a open/closed sourced library for CASifying Websphere portal application.
Do we need to provide CAS filters in wps.ear web.xml or in the web.xml for the portal application war.? Or should be taken care by the TAI interceptor ?
Websphere portal is very rigid to the open source auth libraries!!
Appreciate any help!!
How do I set the fallback page for websphere 6.1 and websphere 8.0?
When I could not load the SPENGO login, I want to have a fallback page to show the simple form login page? Is this possible? Is so, how do I set it up for websphere 6.1 and 8.0?
Unfortunately it is done very differently.
In WebSphere Application Server v6.1 SPNEGO is implemented by the TAI (Trust Association Iterceptor). There is no automatic fallback to default login mechanism, however you can do it by yourself. There are two properties - spnegoNotSupportedPage and NTLMTokenReceivedPage - where you can provide custom pages, which would allow users to access application and bypass SPNEGO challenge e.g. by addinin &noSPNEGO to URL.
For more detailed description of these properties look here - SPNEGO TAI custom properties configuration
In WebSphere Application Server v7 and later SPNEGO is implemented by the web authenticator. It is not configured via TAI properties, but via Global Security > SPNEGO web authentication, there you have option Allow fall back to application authentication mechanism, which will kick in if SPNEGO login fails.
In some cases, default fall back may not work and you will need to define similar properties like in v6.1, but this time via SPNEGO web authentication filter.
For more details look here:
SPNEGO web authentication enablement
SPNEGO web authentication filter
What's the best way to configure SSO between a WebSphere Portal Portlet and a .NET application?
We are using WebSphere Portal 6.1.5 and the portlet should just redirect to the .NET application, but not require the user to login since they already did on portal. Both Portal and .NET app are using same Active Directory(LDAP) for authentication.
SPNEGO is a mechanism that is widely used in WebSphere and Windows for SSO. I am not sure about .Net applications but it is worth your time to explore and see if this would help you in achieving your needs.
Try this for some basic info on SPNEGO and WebSphere
http://www.ibm.com/developerworks/websphere/library/techarticles/0809_lansche/0809_lansche.html
Using same LDAP for authentication does not necessarily mean anything. In most of the SSO scenarios, not all the back end servers use the same LDAP repository. All i am trying to say here is that there is no strong co-relation between the LDAP server and SSO.
HTH
Manglu