Hi, some questions on implementing SSO with WXS.
I have a scenario whereby SSO enabled clients (jsp /servlets etc) in WASND needs to access data in the object grid.
Questions I have are as follows:
1. If the WXS servers are deployed in WASND, is my understanding correct that WSTokenCredential and WSTokenCredentialGenerator are the plugins for SSO?
reference from infocenter: http://pic.dhe.ibm.com/infocenter/wxsinfo/v8r6/topic/com.ibm.websphere.extremescale.doc/cxsprcliauth.html
2. If the WXS servers are to be deployed as standalone JVMs, (clients still deployed in WASND), is it still possible to implement SSO in such a setup? Probably via customized plugins? will this be a supported scenario?
This topic has been locked.
2 replies Latest Post - 2013-01-14T23:14:16Z by lisaw
Pinned topic SSO support in WXS
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-14T23:14:16Z at 2013-01-14T23:14:16Z by lisaw
Art_Jolin 120000NWB626 PostsACCEPTED ANSWER
Re: SSO support in WXS2013-01-14T19:35:42Z in response to phoonwsAs this post has not received an answer from someone in WXS Development or someone that has actually implemented this specific scenario, I decided I would reply with my half-theoretical knowledge. The fact that you have SSO versus not has no effect on this scenario, when you are authenticated to WAS it does not matter if it happened via SSO or separate authentication to this domain. Yes, WSTokenCredential and WSTokenCredentialGenerator are the proper classes for WAS-based authentication to a WXS client. As you mention, the normal scenario is to also use WAS with WXS installed in it to host the catalogs and containers. If you try to use a standalone catalog & containers set, the token probably will not propagate to the cats/containers. However, you can extend the WSTokenAuthenticator class, adding println's on the methods before calling super and try configuring WSTokenAuthenticator into your standalone cats/containers to see if it gets called. If they do not get called, try implementing your own WXS Authenticator class with printlns and configure it in ... if THAT gets called then your only task (likely a nasty one) is to reverse engineer the WAS token and do your own authentication, perhaps directly calling a WSTokenAuthenticator instance as a helper. I have never done anything like this nor do I know anyone who has. I'm not IBM development (used to be a number of years ago, in WAS development) but my very educated guess is that this would be considered an unsupported configuration and you'd be on your own for any problems. In this situation, every customer of mine (I'm an IBM ISSW/Federal consultant) has opted to run cats/containers under WAS and have a supported configuration.
lisaw 0600016B42101 PostsACCEPTED ANSWER
Re: SSO support in WXS2013-01-14T23:14:16Z in response to phoonwsHello. I talked with our security team.
1) The Infocenter article you found is a good start, but you should look at doing a mixed security scenario. What I mean by mixed is that you have your client is WebSphere Application Server and your server is WebSphere eXtreme Scale. This means you probably wouldn't want to use WSTokenCredential because the standalone will not have the required classes to do that. We conviently have a sample of the mixed environment you can try out.
2) You are able to use SSO in a standalone configuration however. You just need to make sure the configuration is set up properly. If you follow the mix security configuration, it would be that you'd need to add these as well.
Client security configuration requires:
Server security configuration requires:
server properties file must define a SecureTokenManager: I.E. SecureTokenManager=default
clusterSecurityFile passed during startup of the servers must contain:
It would definately need a bit of time to work this out, but I think it's possible to setup this way.
Websphere eXtreme Scale Development