This content has been marked as final. Show 2 replies
Steven Smith <> writes:
Obviously, for starters you need jdoe to exist in the security realm
of each cluster - I am assuming you have this already.
One you have this then I believe there are a number of ways you can do
this. If you use IIOP URL's then you will be using CSIv2 and should
find that you are reauthenticated in each cluster. I don't believe
that you need to use IA in this instance.
If you want to use t3 then I believe that you can simply establish
domain trust between each cluster by using the same username and
password for admin. If you do this then the user should be signed in a
way that each cluster understands.
I'm not sure about (c). What you are doing sounds correct.
I guess I am ashamed and embarassed to not know a solution to this problem even after using WebLogic fo so many years.
Here is my problem:
1) I have three weblogic servers - all in different clusters. WebLogic A, B and C. WebLogic A has a web app A.
WebLogic B has a EJB B. WebLogic C has EJB C. The invocation sequence is :
Web App A calls --> EJB B calls --> EJB C
I want to pass the identity of the original user for the entire call sequence.
2)The WebApp A uses a j_security_check and iPlanet LDAP Authenticator to login the end user "jdoe".
3)When I try accessing EJB B from Web App A, I get following error message on WebLogic B - "Invalid Subject: jdoe ".
The error makes sense because WebLogic B does not know about user jdoe. But what steps are required to get this entire A--> B --> C sequence working? I went through the entire WebLogic docs. I cannot find a complete solution to this problem.
a) Do I need to write a custom identity asserter for WebLogic B and WebLogic C that checks the existence of user and his roles from iPlanet LDAP?
b) I tried setting a new default identity asserter and set "Trusted Client Principals" as * and Token Type to be "CSI.PrincipalName". But that didnt help either
c) Furthermore - How can I secure message between the three servers and still pass the identity of "jdoe" ? I used mutual SSL (I set up custom key and trust stores for all servers and also each server trusts other server's key with "client cert enforced" option and used t3s for EJB invocation), but then the ejb invocation worked with
<anonymous> principal - which is not exactly I wanted.
For long I have read about CSIv2 and identity propagation etc. and when I start to implement I just dont know how to proceed.
Any solution and suggestion is appreciated
Here is a complete solution
1)Setup authenticators in all the three weblogic servers
2)Configure the ejb-jar.xml
3)Appropriately coding the Initial Context setup and EJB lookup
4)Setup Keystore and Trust store for all three weblogic servers and make sure that that each server truststore has certificates for others (or that the cert chain can be verified)
5)Configure the weblogic-ejb-jar.xml
The first three ensure that CSIv2 GSSUP tokens are passed appropriately. The last two steps ensure SSL works for EJB
Configure the ejb-jar.xml
Initial context setup and EJB Lookup
For initial context setup, never explicity set the PRINCIPAL and CREDENTIAL. The principals are associated eith the Subject via JAAS - j_security_check in WebLogic A for you. These Principals assoicated with Subject (currently logged in user) are dynamically passed to the JNDI lookup call. If you set the Principal and credentials explicitly, you are messing up the entire delegation (identity propgation) thing.
String contextServiceURL = "corbaloc:iiops:192.168.0.2:8053/NameService";
Hashtable props = new Hashtable();
Context jndiContext = new InitialContext(props);
Object obj = iCtx.lookup("TestEJB");
TestEJBHome ejbHome = (TestEJBHome)PortableRemoteObject.narrow(obj, TestEJBHome.class);
The corbaloc:iiops above is for ssl only. Otherwise use corbaloc:iiop
Also one more thing - I have assumed that the initial context is being looked up everytime. You can very well change it to lookup the EJB home and cache it. Such a setup will work by default in weblogic, since weblogic has a default ,anonymous> prinicpal associated for calls made without principal. It is a different story if the Naming Service / JNDI service is protected and needs authentication. (Frankly I dont know if weblogic allows for secure naming service. But I'd think so. otherwise it is easy for a rogue application to bind/rebind its own rogue object into the naming/jndi service).
Setting up weblogic-ejb-jar.xml
Here is how I would setup the weblogic-ejb-jar.xml
And thats it!!
You've got EJBs in disparate weblogic containers transparently propagating the security context using CSIv2 over IIOP with SSL.