Re: Credentials Propagation? - Weblogic

This is a discussion on Re: Credentials Propagation? - Weblogic ; You have to set up a trust relationship between both WLS Servers (I'm assuming they are in different domains). See http://e-docs.bea.com/wls/docs81/sec...n.html#1171534 If a trust relationship is enabled, the Subject is passed between the WLSs automagically....

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Credentials Propagation?

  1. Re: Credentials Propagation?

    You have to set up a trust relationship between both WLS Servers (I'm assuming they are in different domains). See http://e-docs.bea.com/wls/docs81/sec...n.html#1171534

    If a trust relationship is enabled, the Subject is passed between the WLSs automagically.

  2. Re: Credentials Propagation?

    Here's some additional information to explain (as I've come to understand it) what's going on and what your options (also as I understand them) are. It ties in with the information posted by the other folks.

    The problem:

    You logon to a WLS web application with userid1/pwd1. You are authenticated against the security realm configured for that domain. The configured authentication provider (assume there's only one configured to keep the example simple) authenticates the user id and password, and then creates a user principal and one or more group principals assigned to the user and puts them in the subject. Assuming you are using an out-of-box authentication provider, or a custom provider where the principals extend WLSAbstractPrincipal, WLS security will use its default principal validation provider to sign the principals before they are committed (added) to the subject. The default principal validation provider signing is done using a domain specific key. This key is generated uniquely for each WLS domain, but you can change it to establish a trust (to be described in a bit).

    The first time that the subject is used in an authorization decision, the signature of the principals will be validated by the same principal validation provider that signed them (in this case the default). This is to prevent the forging of principals in a subject.

    So now you are executing code within a request thread and you come to a point where you're ready to do the cross domain call (invoke the remote EJB in another WLS domain). If you do the JNDI lookup without an id and password, the existing subject will be passed to the target domain and used by the call there. This will fail because the other domain (by default) has a different principal signing key. So when the principal validation provider over there tries to validate the signature in the principals, it fails because the keys in each domain are not the same.

    So one option is to set up a cross-domain trust as recommended in the previous post. As I understand it BEA does not recommend this in a production environment. I think partly because such a trust would be transitive. That is if WLS domain 2 trusts WLS domain 1 and WLS domain 3 trusts 2, 3 also trusts 1 (because the same key is shared among the three).

    Another option would be to write your own principal validation provider that uses a different signing approach and/or does domain check filtering. Problem here is that you would need to develop your own custom principal classes (that do not extend WLSAbstractPrincipal), your own custom authentication provider, and your own principal validation provider. You also have to deal with storing the signature keys, any filtering lists, etc. In short this is doable, has some advantages (e.g. you don't need to do explicit JNDI lookups with ID and password), but is not cheap/trivial.

    Another option, as stated in the previous post is to do an explicit JNDI lookup for the target EJB with an ID and password. A couple of issues here. 1, you will likely not have the password of your original user anymore. And even if you did, if the WLS domains have different user bases it wouldn't work anyway. So you'd probably need to use some type of service account for the JNDI authentication. Then you need to consider if you have to communicate information about the original user, perhaps for auditing purposes. Finally, as you've discovered, after you do the JNDI lookup with ID and password, the remainder of your request processing on the client WLS server will continue to run under the context created by the JDNDI lookup (if you dump the subject after the JNDI lookup but before your next web request comes in, the subject will be populated with principals corresponding to the JNDI credentials - after the next web request comes in, the subject reverts back to that of the user).

    The run as approach may be the lowest hanging fruit, but I haven't done any prototyping with it yet. I know you can configure the EJB descriptor with run as information. But I'm not sure if the run as context (subject) is only on the target server or also on the client server, and if you have the same issue as with the JNDI lookup with ID and password with regard to the subject not reverting back to the user's until the next web request. You can also use the API mentioned to explicitly create your run as subject (but you'd still need an id and password). I'm pretty sure that with the API, the subject reverts back to that of the user after the call to run as (so the run as deployment descriptor probably does too), but you'd want to test to be sure.

    I know this doesn't directly solve your issue, but hopefully it helps you understand what's happening under the covers, and more about what your options are.

    Jim

  3. Re: Credentials Propagation?

    > So one option is to set up a cross-domain trust as
    > recommended in the previous post. As I understand it
    > BEA does not recommend this in a production
    > environment. I think partly because such a trust
    > would be transitive.

    This is fine in production environments, and I have seen production environments using this. AFAIK there is no blanket recommendation against this. Security is only as strong as the weakest link: trust between domains requires that both domains have appropriate security measures installed.

    Setting up a trust relationship is the easiest alternative.

  4. Re: Credentials Propagation?

    Sorry for the over-generalization in my previous post. The exact disclaimer in the BEA documentation is:

    Note: BEA Systems does not recommend enabling trust between WebLogic Server domains in a production environment unless the servers have a secure means of communication such as a dedicated line or are protected by a firewall.

    Since the above is usually true in a typical production configuration, I would agree with you.

+ Reply to Thread