Is this a security hole, or working as designed? - Weblogic

This is a discussion on Is this a security hole, or working as designed? - Weblogic ; I was doing some testing and noticed the following behavior. This doesn't seem right. This is on WL 8.1 SP 2. - Using realm with WL Default Authenticator (no other custom providers) - Created a user juser and the groups ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Is this a security hole, or working as designed?

  1. Is this a security hole, or working as designed?

    I was doing some testing and noticed the following behavior. This doesn't seem right. This is on WL 8.1 SP 2.

    - Using realm with WL Default Authenticator (no other custom providers)
    - Created a user juser and the groups G1, G2 and G3
    - Assigned G1 and G2 to juser
    - Deployed a web application with a root url namespace requiring G1 membership to access it, and an additional url with a protecting policy that requires G3 membership.
    - Wrote a servlet that uses the security API to fetch the current subject. It then attempts to directly modify the subject by adding a new WLSGroupImpl object with name G3 to the principal set.

    - When I access the home page, I'm forced to authenticate. Dumping the principals reveals juser, G1 and G2 as expected.
    - I am unable to hit the URL that requires G3 membership (as expected).
    - I hit the servlet that does the direct manipulation of the subject.
    - Dumping the principals now reveals juser, G1, G2, and G3 (not expected - thought this would fail)
    - I can now hit the URL that required G3 membership (definitely not expected)

    - I also tested a call to an EBJ method that directly modified the subject. Same behavior.

    - If I were to make a cross-domain EJB call (first setting the domain credentials in each domain to match) after running through one of the above scenarios that forced G3 into the subject, the subject on machine 2 (domain 2) only shows juser, G1 and G2.

    I was under the assumption that the only way to mutate a subject was through a security provider or a security API that required some type of credentials. Where am I off base?

    Thanks in advance for any input.

    Jim

  2. Re: Is this a security hole, or working as designed?

    We discovered that there is a setReadOnly() method on the subject. If you call this on the subject at the end of the LoginModule's commit() method, the subject is immutable. Don't think this would cause any issues unless there were a chain of authenticators, and an authenticator to follow also could authenticate the user and attempt to populate the subject.

    Also, assuming setReadOnly() is not called, although you can create a new principal and add it to the subject, you can't sign it because it's a privileged operation to fetch the principal validator's signing credntial.

+ Reply to Thread