authenticationwebspheresingle-sign-onwebsphere-libertyltpa

How does LTPA works as a SSO(single sign on) mechanism


I've got a basic knowledge of SSO principle from a good blog article Visit https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/#

And I think to realize SSO, we use a central domain(such as LDAP or other Authentication Server) for authentication and it can generate token and stored as a cookie or just in browser's storage.

Next time we visit an application in another domain, it redirects to Auth Server and can use the token we stored before, then we can get a new cookie includes this token for our the domain we want to visit.

By this way, I think that SSO is to use a central Auth Server as a third hosted server or we can call it a delegation server to generate different cookies for different domains, in this way we resolve the Single Origin Policy(cookie can only be accessed by its creator and cannot be cross domains).

If that's the way SSO works, I'm confused about IBM LTPA. I'm using WAS and from the guide, if I want to realize SSO, I need to get a LTPA key generated from first server, and copy it to each server I want to make a SSO function. The LTPA key includes a public Key and a Private Key to decrypted LTPA token which generated by WAS.

So if I use a LDAP as an Auth Server, first I visit my application on domain 1, my request will be redirected to login page and after an authentication in LDAP(here I don't think LDAP will generate a token), WAS will generate a cookie with an LTPA token, but when we want to visit an application in domain 2(WAS in this domain has got the LTPA key), our LTPA token can be decrypted and we got our userId(or some field can identify the user), then we go to our LDAP Auth server again to verify this userId...

I don't know if my understanding is right but I don't think this can be called as "SSO". Because, first, the token we got is generated by WAS,not LDAP, so what we got is just a userId and when we decrypted this token, we need to verify this user again in LDAP. Second, what we use to make SSO work is deliver a cookie with a LTPA token, but cookie cannot be sent across domains....So if domain 1 and domain 2 are not the same Realm, this just cannot happen... because we cannot get the cookie in domain 2...

I'm nearly mad about it...

Who can tell me how LTPA works as an SSO mechanism exactly by using LTPA keys....

Thx so much!


Solution

  • LTPA is single sign on among different applications deployed on WebSphere (and some other IBM products, like for example Domino). Its basic functionality is to work in one cell, between various apps in various servers, or in more complex scenarios between cells (where you exchange keys). As you already found out, it is not cross DNS domain, so it is rather limited to single company (subdomains are supported although). It also supports downstream propagation of the credentials via IIOP, if you have for example remote EJBs.

    If you are looking for cross domain SSO mechanism, WebSphere supports SAML and Open ID Connect.