SAML – Enterprise SSO in the WebSphere world

SAML – Enterprise SSO in the WebSphere world

Hi all, this time I want to introduce a very „hot topic“ – SAML SSO. I want to give a brief overview what this is and what role it plays in our WebSphere world.

So let`s get started

What is SAML

SAML (or Security Assertion Markup Language) is a standard for exchanging authentication- and authorization data between different security domains. While SAML only describes the data exchanging protocol, the term is also used as a generic term for built on top SSO scenarios. SAML can be used regardless of manufacturer so that it is possible to integrate systems of a various number of software manufacturers. Especially this makes SAML really like a Swiss army knife when it comes to Cloud / hybrid Cloud integrations. SAML 2.0 is the actual standard (since 2005). Version 1.1 is still available and used.

SAML is a very safe procedure. It is easy to handle.

Customers who think about moving parts of their infrastructure into a cloud should think about using SAML because it is not mandatory to store registry data (LDAPs) outside the company`s network (depends on the software that is used)

 

How does SAML work

For the general concept, please have a look here

There are two different approaches how SAML SSO is initiated:

Service Provider initiated SAML

The user accesses a service provides (any SAML activated application). The service provider redirects the user to an IdP (Identity provider – e.g. ADFS server, ISAM for Web) where the authentication takes place. IdP redirects the user back to the service provider (User is logged in)

The authentication flow (SP Initiated SAML):

SAML5

  1. User accesses SP
  2. SP returns „401“ and redirects browser to IdP
  3. Browser accesses IdP URL.
  4. IdP returns SAML token with assertion to the user
    1. Browser is redirected to SP
    2. Browser sends query to SP with embedded SAML Token
    3. SP checks SAML token validity based on the trust relationship with IdP
    4. SP grants access to the resources

Identity Provider initiated SAML

In this case the user first logins on the IdP in order to be able to use the protected resource. There is no redirect from the SP to IdP.

The authentication flow (IdP Initiated SAML):

SAML6

  1. Authentication of user against IdP
  2. IdP returns SAML token with assertion to the user
    1. Browser is redirected to SP
    2. Browser sends query to SP with embedded SAML Token
    3. SP checks SAML token validity based on the trust relationship with IdP
    4. SP grants access to the protected resource

In many cases, SP initiated SAML is used.

WebSphere does not support „pure SP initiated SAML“ in the current version. WebSphere Application Server is not able to create the mandatory SAMLRequest (mandatory per Standard definition). But there is a TAI (Trust Association Interceptor) available (acs application) that performs the first step of SP initiated SAML (redirect of SP to IdP). The acs application detects that the user is not authenticated and performs an IdP redirect (based on the information that was configured while setting up SAML).

 

WebSphere and SAML

Generally, support it given for WebSphere Portal and IBM Connections (main products I work with). Additionally, many more products such as Domino support SAML. Support for SAML means first of all that the underlying WebSphere Applications server contains the mandatory components to acts as a SAML Service provider.

 

There are some special considerations when talking about SAML support in WebSphere Portal & IBM Connections.

IBM Connections

  • Cognos does not support SAML. In this case you need to setup a separate Cell for Cognos and realize SSO via LTPAToken.
  • MobileApp support for SAML is not available
  • SAML-Support for HTTP Outbound Connections Service (old name was AJAX Proxy) authentication via SAML is rather unclear in IBM Connections. There are some information how to integrate parts of Smartcloud (that uses SAML) but that`s it.
  • SAML-Support for CCM does not seem to be working

WebSphere Portal

  • Support for HTTP Outbound Connection Service (old name was AJAX Proxy) authentication via SAML was added since WebSphere Portal 8.5 CF03. So quite new and officially supported for ISAM for Web / ADFS server.

 

How to configure WebSphere for SAML usage

In this example I want to show you how to configure WebSphere software for SAML usage. In this case an ADFS server was used as IdP

Assumption:

I assume that you`ve already setup the ADFS server and configured it correctly.

Install the ACS application

1. Access ISC –>  https://SERVERNAME.DOMAIN.COM:9043/ibm/console

2. Goto – Applications – Install New Middleware Application

SAML1

3. Choose the AppServers installableApps directory and mark the application “WebSphereSamlSP.ear” – this is the ACS application that will perform the redirect for you as an unauthenticated user to the IdP

SAML2

4. Map the application to one of the servers (InfraCluster for example) and map it to the webserver

SAML3

5. Regenerate the WebSphere Plugin, Sync the nodes, restart the webserver and start the “WebSphere SamlSPWeb” application

Configure WebSphere TAI

1. Change to Security – Global Security – Web and SIP Security – Trust association

SAML4

2.

SAML8

Click “New” and enter the Interceptor Class name:

com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor

3. In the next step you need to define custom properties for this Interceptor

SAML10

The following explainations are taken from IBMs Knowledge Center

sso_1.sp.acsUrl

It specifies the URL of the ACS or business application

sso_1.sp.idMap

This property specifies how the SAML token is mapped to the subject

The following values are valid:

  • idAssertion (Default) – the user specified in the SAML assertion is not checked in the local registry
  • localRealm – the SAML token user is verified in the local user registry
  • localRealmThenAssertion – if the user is found in the local registry, IDAssertion is used

ssp_1.sp.trustStore

This property specifies the truststore for validating the SAML signature. It specifies the name of a managed keystore. Actually into which keystore you will import the ADFS Server certificate.

sso_1.sp.targetUrl

targetUrl where the IdP should redirect to after the SAMLResponse has been validated

sso_1.idp_1.entityID

This property is used to verify AudienceRestriction in the SAML assertion

sso_1.sp.useRelayStateForTarget

This property specifies whether the RelayState value received in the client request should be used as the URL of the target application or not. If this property is set to false, the sso_<id>.sp.targetUrl property is used as the URL of the target application.

sso_1.sp.enforceTaiCookie

This property is used to indicate if the SAML TAI should check if an LTPA cookie is mapped to a subject created for the SSO partner.

sso_1.sp.useRealm

This property specifies a realm name and is used to override the default realm. This property also overrides the realmName property.

sso_1.sp.login.error.page

This property specifies the error page, IdP login page, or custom mapping class to which an unauthenticated client request is redirected to.

sso_1.idp_1.singleSignOnUrl

This custom property specifies the URL of the SSO service of the IdP

sso_1.idp_1.certAlias

Name of the Certificate alias of the ADFS certificate stored in the truststore

sso_1.sp.filter

Filter values, for which applications / targets SAML should be active or not

4. Goto “Global Security – custom properties” and change the values:

com.ibm.websphere.security.DeferTAItoSSO

and

com.ibm.websphere.security.InvokeTAIbeforeSSO

to:

SAML11

5. Restart the appserver

6. Export the SAML configuration using wsadmin

 

wsadmin.sh -lang jython
AdminTask.exportSAMLSpMetadata('-spMetadataFileName /ibm/spdata.xml -ssoId 1')
quit

7. Copy the file spdata.xml to the ADFS server
8. Open the ADFS 2.0 management snap-in
9. Open “Trust relationships – Relying Party Trust” and click “Add Relying Party Trust”

SAML12

10 . Provide the spdata.xml file you`ve generated using the wsadmin command

SAML13

11. Enter the IBM Connections Server hostname

SAML14

12. You want to permit each user to get access to the Service Provider using SAML

SAML15

13. You need to edit the “Claim Rules Dialog” where you generate a mapping between your AD and your participating Service Provider

SAML16

14. The calim rule you want to use: “Send LDAP Attributes as Claims”

SAML17

15. here you click “Add rule” to insert a new claim rule

SAML18

16. you map the sAMAccountName to Name Id

SAML19

–> Here you can read more about claim rules

Export the SAML token signing certificate and import it into the WAS truststore

1. On the ADFS server start the AD FS 2.0 Management and go to “AD FS 2.0 → Service → Certificates”. Select the Token-signing certificate and click “View certificate”:

SAML20

2. Export the certificate in the DER encoded binary format

SAML21 SAML22 SAML23 SAML24

Import the token signing certificate into the WebSphere Application Server truststore

1. Goto “Global Security – SSL certificate and key management – Key stores and certificates – CellDefaultTrustStore – signer certificates” and click add – choose the ADFS certificate

SAML25

Choose the correct values you specified for:

sso_1.sp.trustStore (here I use CellDefaultTrustStore)

sso_1.idp_1.certAlias (here is used saml_ADFS.SERVER.COM)

Add the ADFS Server to the trusted authentication realms 

SAML26

Add

http://adfs.server.com/adfs/services/trust

https://adfs.server.com/adfs/services/trust

and further alias if there are any

–> Restart the IBM Connections server and you are ready to test the implementation

Testing

Access –> https://connections.server.com

you will be redirected to the ADFS server (Idp Initiated Login Page)

Choose your IBM Connections Server

SAML27

Enter your credentials and voilà you are signed in IBM Connections 😉

Summary

I think there are some more or less complex configuration steps to do. But if you once did those, you will understand the procedure. If you do not have an ADFS server, you can also use other IdPs that support SAML 2.0. Some steps might be different there.

So go for it and test SAML. I hope you will like it easy much as I do 😉

8 thoughts on “SAML – Enterprise SSO in the WebSphere world

  1. Thank you some much for this article. I need to do similar setup with WebSphere Portal 8.5 and WebSEAL. Do you have steps for those? I would really appreciate it if you could point me to details.

  2. Hi
    I’m trying to configure SAML SSO with WebSphere Portal 8.5(CF8, running on top of WAS 8.5.5.7) and AD FS as IDP. The AD FS is running on Windows Server 2012 and Portal on Windows 7.

    The configuration is as follows –

    1. TAI custom proprties
    sso_1.sp.acsUrl=https://portalserver:10142/samlsps/wps/
    sso_1.sp.filter=requesturl%=/wps/myportal/*
    sso_1.sp.idMap=localRealm
    sso_1.idp_1.entityID=http://adfsserver/adfs/services/trust
    sso_1.idp_1.SingleSignOnUrl=https://adfsserver/adfs/ls/
    sso_1.sp.login.error.page=https://adfsserver/adfs/ls/IdpInitiatedSignon.aspx
    sso_1.sp.trustStore=NodeDefaultTrustStore
    sso_1.sp.targetUrl=https://portalserver:10142/wps/myportal/
    sso_1.sp.useRelayStateForTarget=false
    sso_1.sp.enforceTaiCookie=false
    sso_1.idp_1.certAlias=adfscertalias
    sso_1.sp.trustAnySigner=true
    sso_1.sp.wantAssertionsSigned=false
    sso_1.sp.useRealm=defaultWIMFileBasedRealm

    2. Global Security custom properties –
    com.ibm.websphere.security.DeferTAItoSSO=com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor
    and
    com.ibm.websphere.security.InvokeTAIbeforeSSO=com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor

    3.Trusted authentication realms – inbound, added following entries –
    http://adfsserver/adfs/services/trust
    and defaultWIMFilebasedRealm

    4. The Token-signing certifcate exported from AD FS in .cer format is imported under
    Global Security –> SSL certificate and key management –> Key stores and certificates –>
    NodeDefaultTrustStore –> signer certificates with alias ‘adfscertalias’.

    5. The exported SP metadata(using AdminTask.exportSAMLSpMetadata) from WAS is used to configure the Relying Party Trust in AD FS.

    Now the AD FS login screen(https://adfsserver/adfs/ls/IdpInitiatedSignon.aspx) is showing the WebSphere Portal server as a partner site.

    When I enter user Id and password in AD FS login, I am logged in successfully then the browser redirects to Assertion Consumer endpoint https://portalserver:10142/samlsps/wps/.
    But after this, nothing happens.

    In Sysout log, I find an FFDC entry.
    . The FFDC log, has the following stacktrace –
    FFDC Exception:java.lang.IllegalArgumentException SourceId:com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor.invokeTAIbeforeSSO ProbeId:545
    java.lang.IllegalArgumentException: key:null
    at com.ibm.ws.cache.util.ValidateUtility.objectNotNull(ValidateUtility.java:47)
    atcom.ibm.ws.cache.DistributedObjectCacheAdapter.common_get(DistributedObjectCacheAdapter.java:553)
    ……..
    So far the configuration changes that I applied didn’t solve the problem.
    Note that if I hit the AD FS entity url (http://adfsserver/adfs/services/trust) in a browser, I get a Service Unavailable (503) error. Does this mean AD FS is no configured correctly?

    Any idea, what’s going wrong here?

    1. Hi,

      not sure, what`s the real problem here. But some things that look strange to me:

      sso_1.sp.filter=requesturl%=/wps/myportal/*

      –> this should be request-url%=

      ADFSServer and WebSphere portal are running under the same SSO Domain?

      Did you enable traces on portalserver:

      com.ibm.ws.security.web.saml.*=all

      Did you set the Claim rule?

      I also get the 503 error on my ADFS Server when accessing it directly. SAML SSO works perfectly on my portal server… So I ignore this but I do not know for sure why a 503 error is shown.

      1. Hi

        Thanks for your reply. The requesturl%=/wps/myportal/* was a typo that I fixed, but then ran into another issue and it turned out that there is a bug in WAS 8.5.5.7 according to this APAR PI47842 for which the IdP initiated flow fails. I ended up downgrading the Portal WAS to 8.5.5.6 and the IdP initiated flow is working now. Also the SP redirects to IdP initiated flow seems to be working.I’m now into the SP initiated flow for which I need to create a AuthnRequestProvider to send the SAML AuthnRequest to ADFS. But so far whatever request I send to ADFS 2.1 it rejects it as being invalid. I would not clutter your page with the details of this new error but I have raised this issue in Microsoft forum here, please take a look – https://social.technet.microsoft.com/Forums/windowsserver/en-US/8199a8b3-013a-4d94-975a-e8d3c6b883de/msis7015httpsamlmessageexception-in-adfs-21?forum=winserverDS

        My question is have you tried the SP-initiated flow with WebSphere and ADFS? The support for the SP-initiated flow in WebSphere is relatively new as per this link –

        I have enabled trace logs both in Portal and ADFS 2.1 so would share any logs if required.

        This article has been really helpful in manually setting up AD FS as the IdP in WAS as the recommended approach(as per KnowledgeCenter) for running the AdminTask.importSAMLIdpMetadata fails.

        As for same domain, yes, Portal and ADFS 2.1 are in same domain as in –
        portal.mydomain.com and adfs.mydomain.com.

        You have mentioned something about claim rules, but I haven’t configured that yet though the IdP flow is working without it. Could you please tell why that 503 error comes up in ADFS for it and whats the implication of that.

        I need to try out the SAML SSO with the HTTP outbound proxy also, but once I get through with the SP flow.Basically I need to try out every option with SAML SSO using WebSphere and ADFS and present that to the customer.
        Thanks for your help so far.

          1. Hi,

            I know that WebSphere now also supports SP initiated flows… But I never tried that. Sorry, I think I cannot help you with that.

  3. down vote
    favorite
    Yesterday I configured SAML between OKTA and WebSphere Application Server for APP1. It is working good.

    The Client has a new requirement to access the same App1 via WAS directly too on the same OKTA WAS.As a resolution I configured the VHost as well as defined a new port to achive it.The behavoure is starange when I access the application the new VHOST or even the new port the application is routed to the OKTA IDP.

    Any help,suggestion or idea regarding this will be highly appreciated.

    Many Thanks,

    Umar

Leave a Reply

Your email address will not be published. Required fields are marked *