[jboss-as7-dev] On security context and propagation

David M. Lloyd david.lloyd at redhat.com
Thu Feb 28 18:18:06 EST 2013 

Generally there are two ways you can go when it comes to supporting 
multiple client identities on the server.

#1) Implicit client trust.

In this example, the client authenticates as a user who has authority to 
act on behalf of other users (perhaps a limited set).  In this sense, 
sending a whole Subject is not really necessary but either way it's an 
implementation detail.

#2) Untrusted client authenticates to other user.

In this example a client wants to run as a different principal than the 
one they've authenticated to, but they do not have implicit authority to 
run as that user.  In this case the client must authenticate to the new 
user.  However you generally can't use your typical JAAS scheme because 
the CallbackHandlers generally entail cleartext passwords and that sort 
of thing, which you cannot or should not send over the network.  It is 
more advisable to use authentication mechanisms designed for network 
operation - SASL, GSS, or similar.  The result of this authentication is 
a token which can be used as an indicator to the server that a given 
invocation is to run on behalf of this new identity instead of the 
connection's default identity.

When this token is sent back to the server though, it need not be done 
in the full form of a Subject, since it's most likely going to be a 
number with a length of just a couple of bytes and serializing the whole 
Subject will (at the least) be much larger and (more dangerously) might 
even expose sensitive information across the network needlessly.

Serializing Subjects in the obvious way, thus allowing credentials to be 
blindly sent over the network, is a potential exploit waiting to happen 
in my opinion; the idea makes me nervous.

In either case though, it is possible that we could support an object 
substitution mechanism (at least for our EJB invocation protocol) which 
detects Subjects that are known to the connection (either as a token or 
as the default subject of the connection, if we have such a thing), and 
substitutes them with an indicator containing the token in question; 
then on the receiving side a corresponding local Subject is looked up or 
generated and used for the invocation context Subject.  Unknown Subjects 
serialized by the client could be handled in some different way, possibly.

Alternatively we could simply be very cautious about what credentials 
and principal types we allow on a Subject, but I'd be worried about a 
malicious client seeding a Subject with (for example) roles to which 
they should not be allowed and that sort of thing.  It seems very easy 
to exploit to me.

On 02/28/2013 03:19 PM, Radoslaw Rodak wrote:
> Why not distinct between Network auth and Appl Security propagation …?
>
> Let say you use something else ( AS7 SASL ) for Network auth.
> Once Network auth was successful with else ( SASL )  you have established connection, where you can send data.
> What would speaks against to send with the data the JAAS Security Context ( Subject ) to other side and use it on remote side and call Subject.doAs ?
>
> For additional  trust between AS Servers you could add Jboss Specific principal containing some encryption which could valides on remote side.
>
> And if you worry about transport safty, SSL channel could be used as Network connection.
>
> Radek Rodak
>
>
>
>
> Am 28.02.2013 um 21:16 schrieb David M. Lloyd <david.lloyd at redhat.com>:
>
>> As long as everything is Subject-based, the authentication API used
>> shouldn't matter.  JAAS is probably OK for local in-VM auth, it just
>> falls apart for network auth.  But it should be possible to support
>> alternatives (if there even are any) as long as they authenticate to a
>> Subject.  We could even retrofit our EJB client network auth service to
>> use the JAAS API, in all likelihood.
>>
>> On 02/28/2013 01:57 PM, Anil Saldhana wrote:
>>> Except for the ACC stuff - everything you state is PicketBox.
>>>
>>> As we discussed in IRC, I think this is a good idea as long as we have
>>> good tests for the various usecases.
>>>
>>> There is huge backlash against JAAS. Need to hear suggestions for
>>> authentication.
>>> There is the PicketLink IDM based authentication.
>>>
>>> On 02/28/2013 12:30 PM, David M. Lloyd wrote:
>>>> The Problem
>>>> ===========
>>>> In order to support all the Java EE 7 requirements, we need to be able
>>>> to propagate security context in a predictable and uniform manner.
>>>> Unfortunately, we have almost as many security context concepts as we do
>>>> projects which support authentication.  There is no single way to
>>>> execute a task given a security context snapshot from another thread
>>>> that will work for all of our projects.
>>>>
>>>> Project-Specific Security Context
>>>> ---------------------------------
>>>> The typical implementation of a project-specific security context is
>>>> just a Subject, cached into a ThreadLocal and available via some
>>>> accessors.  In addition we have the SecurityRolesAssociation concept
>>>> from PicketBox, which is meant to encapsulate roles from an EE perspective.
>>>>
>>>> Available Mechanisms
>>>> ====================
>>>> A number of mechanisms are provided by the JDK and the EE SDK
>>>> specifically for addressing this problem domain.  Here's a quick review
>>>> so we are all speaking the same language.
>>>>
>>>> javax.security.auth.Subject
>>>> ---------------------------
>>>> The focal point for security in both SE and EE is the Subject class,
>>>> which is an encapsulation of related information for a security entity,
>>>> including credentials (passwords, keys, etc.) and identities (user/group
>>>> names, roles, etc.).  Most (not all) of our security-aware projects
>>>> already seem to use Subject, though they may not all be using it in the
>>>> same way.
>>>>
>>>> Subject has some utility methods which are intended to allow association
>>>> with the current security context.  With these methods you can run tasks
>>>> as different Subjects.  We currently do not support these methods.
>>>>
>>>> java.security.Principal
>>>> -----------------------
>>>> The base interface for an identity.  Though there are no specific
>>>> supported implementations for EE use cases, this interface would be the
>>>> base for user names, group names, role names, and so on.  JDK Principal
>>>> implementations do exist for filesystem users and groups, certificate
>>>> signers and principals, JMX authenticated identities, etc.
>>>>
>>>> java.security.AccessControlContext ("ACC")
>>>> ------------------------------------------
>>>> This is *the* JDK-provided security context.  It represents the
>>>> accumulated privileges of "protection domains", which can in turn
>>>> correspond to principals, permissions, and/or code sources (i.e. JARs).
>>>>     A given ACC, in simplified terms, represents the *intersection* of
>>>> privileges granted by all the invocations on the call stack.
>>>>
>>>> It gets a bit complex once you plumb the depths but imagine ACC
>>>> conceptually like a second execution stack.  Every time you call into
>>>> another module, you push another layer on the stack which includes that
>>>> module's permission set (which is AllPermission by default, but can be
>>>> restricted on a per-module basis).  This also includes calling into
>>>> deployments.  You can also push a Subject on to this stack using
>>>> Subject.doAs*().
>>>>
>>>> It is worth emphasizing that the effective permission set for an ACC is
>>>> the intersection of all of its parts, so the more calls you make, the
>>>> more restricted your permissions are.  This is why we use
>>>> AccessController.doPrivileged*() and/or Subject.doAsPrivileged(): it
>>>> "clears" the stack for the duration of the invocation, adding only the
>>>> module which hosts the Privileged*Action class being executed (and
>>>> optionally the given Subject as well).  This becomes important when you
>>>> consider that in many cases, you have no idea under what context a given
>>>> piece of code will be run, thus you cannot be certain whether a
>>>> restricted operation will succeed without using doPrivileged().
>>>>
>>>> Perhaps the canonical case of this is class initialization.  Common
>>>> sense would seem to imply that classes should always be initialized in a
>>>> privileged context, but that does not seem to be the case in reality.
>>>> Thus class init is often stuck with awkward doPrivileged constructs,
>>>> especially when field init is involved.
>>>>
>>>> A Unified Security Context
>>>> ==========================
>>>> The ACC affords us a uniquely suited mechanism for security association.
>>>>     Subjects are already designed to be connected into ACCs; in fact, you
>>>> can query an ACC for its associated Subject with a simple get.  In turn
>>>> the Subject can be queried for its Principals and credentials.
>>>>
>>>> This also gives us saner integration with JAAS, to the extent that such
>>>> sanity is possible; users can use the returned Subject with
>>>> Subject.doAs() and get the results they would expect in any situation.
>>>>
>>>> Finally ACC is in the JDK - any third-party security-aware framework is
>>>> much more likely to integrate with ACC and Subject than with some
>>>> framework provided by us.  And, the JDK security manager framework is
>>>> ready to handle it, so a user security policy could for example forbid
>>>> certain Subjects from performing operations as an additional security layer.
>>>>
>>>> Getting the Current Subject
>>>> ---------------------------
>>>> To get the current subject you can do something like this:
>>>>
>>>>       Subject current = Subject.getSubject(AccessController.getContext());
>>>>
>>>> This will work from any context - though there is a permission check
>>>> involved so a security action is in order in this case.
>>>>
>>>> Propagation Within the AS
>>>> -------------------------
>>>> We need to do in-system propagation of security context in a few
>>>> situations.  The predominant one (to me) is using JSR-236 thread pools -
>>>> tasks submitted by an EE component must run under the same security
>>>> context that the submitter holds.
>>>>
>>>> Fortunately propagation of this nature is quite simple: use
>>>> AccessController.getContext() to acquire the current security context,
>>>> and use AccessController.doPrivileged() to resume.
>>>>
>>>> Propagation to other components (e.g. EJBs) is a little different
>>>> though.  In this case you do not want the baggage of the caller ACC; you
>>>> only need to preserve the caller Subject.  In this case, you would
>>>> acquire the Subject as above, and the security interceptor would simply
>>>> use Subject.doAs() to resume.
>>>>
>>>> Propagation Over the Network
>>>> ----------------------------
>>>> It should be possible to use Principal information stored on the Subject
>>>> in combination with private credentials to provide all the information
>>>> required for network propagation of security context.  This should work
>>>> particularly well with the Remoting authentication service in particular.
>>>>
>>>> One Step Farther: ACC-Based Permission Checking
>>>> -----------------------------------------------
>>>> It is possible to take this idea a little farther and introduce
>>>> permission checking for JACC-style permissions based on the ACC.  Using
>>>> ACC.checkPermission we can do permission checking regardless of the
>>>> presence or absence of a SecurityManager.  However, it is not clear what
>>>> benefits we would derive from this move (if any).
>>>>
>>>> Costs and Alternatives
>>>> ======================
>>>> ACC is not free.  It's a fairly heavyweight structure (though it does
>>>> make certain optimizations in some cases), and it contains what is
>>>> probably more information than is strictly necessary as it is designed
>>>> for full-bore SecurityManager sandboxing and permission checking.  Thus
>>>> it is worth exploring alternatives.
>>>>
>>>> Alternative: Central Security Context
>>>> -------------------------------------
>>>> Alternative #1 is to support a central security context represented by a
>>>> Subject in one place which all frameworks and libraries share.
>>>>
>>>> Pros: lightweight (as much as possible anyway); conceptually simple
>>>> Cons: not compatible Subject.doAs or AccessController.doPrivileged;
>>>> additional dependency for all security-aware frameworks; third-party
>>>> stuff is less likely to just work
>>>>
>>>> Alternative: ???
>>>> ----------------
>>>> Add your ideas here!
>>>>
>>>> Action
>>>> ======
>>>> I think, barring any major dissent, we should make a move towards using
>>>> ACC as a unified security context.  I think that given the EE 7 security
>>>> manager requirements and user requests over time, that standardizing
>>>> around ACC makes sense.
>>>>
>>>> Discussion: go!
>>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
- DML

More information about the jboss-as7-dev mailing list