2

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!

Jiddu.K
  • 69
  • 9

2 Answers2

1

The LTPA is a mechanism to shift the authentication from WebSphere (or backend server) to a SSO server - lets talk about IBM ISAM (WebSeal)

User--->ISAM SSO (WebSeal)- LTPA goes here---->backend server WAS)

Generally the backend WAS server does not do any authentication itself. User authenticates to SSO server,and SSO servers sends encrypted LTPA token to backend server that contains users usename (usually only username, group membership but never passwords). Backend server decrypts LTPA and as the LTPA and trusts it. Then Backend application server (WAS) pass this authentication details into application.

Please see an example of putting IBM Cognos (application on WAS) behind SSO server.

http://www-01.ibm.com/support/docview.wss?uid=swg24022695

Marcin P
  • 430
  • 1
  • 5
  • 11
  • Hi Marcin, thx for your answer, but I still have some confusions...is the SSO server you mentioned a independent server? so it's not for application but just for authentication? What we use for our applications now are 2 WAS-Liberty servers, and an LDAP server for authentication. I thought we need to set our Liberty 1(2 liberties are both for applications) to LDAP server for authentication, once it passes, we can visit our application on Liberty 2 without authentication(such as a logon page). I call this scenario as SSO... – Jiddu.K Apr 15 '17 at 17:35
  • Due to characters limit, I will continue here.I think what we did is to make both 2 Liberty servers as "SSO" server.they share the same LTPA key generated by Liberty1 as we added the LTPA feature on it.So I think the LTPA token is generated by Liberty 1 and when we send it(by cookie) to Liberty 2 as we want to visit our application on that server, maybe we cannot make it because they don't in the same domain and cookies cannot be sent across domains,So how can we call it an SSO? I think your suggestion is that we make an SSO Server as authentication server and both Liberty connect to it? – Jiddu.K Apr 15 '17 at 17:42
0

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.

Gas
  • 17,601
  • 4
  • 46
  • 93
  • Thx so much,@Gas! It's really helpful! Thanks a lot for your reply! That's exactly the answer I want. I'm looking SAML for my requirement! – Jiddu.K Apr 18 '17 at 01:11
  • I've accepted your answer, due to my low reputation...I cannot vote, sorry for that... – Jiddu.K Apr 19 '17 at 09:26