On security context and propagation

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

On security context and propagation

David Lloyd-2
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!

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Anil Saldhana
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

David Lloyd-2
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Bill Burke
In reply to this post by David Lloyd-2
First of all, IIRC, all the EE components already have a unified
security context.  Servlet, EJB, JCA.  (Not sure about HornetQ).  And
you could propagate the security context from the servlet tier all the
way to your database in one call stack.  These already build off of
Principal and Subject as Anil said...but...

You can build off of Principal, Subject, and ACC, but you'll still need
to define how permissions/role mappings can be created as well as
introspected..  As a protocol developer, I can't really do much with a
Principal and Subject and ACC without knowing how populate a Subject
with metadata or knowing how to extract specific metadata from it.  The
interfaces you mention are just too generic and targeted specifically to
check permissions.

For example, if I want to turn the current security context into a token
that contains digitally signed identity and permissions, the
aforementioned interfaces don't really have anything defined that allow
me to get at this information.

As far as JAAS goes, the fact that it is completely stateless or backed
by a component model makes it impossible to use even in-VM.  You can't
pre-initialize or pool DB or HTTP connections.  You can pre-load or
initialize keys or other configuration information.


On 2/28/2013 1: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!
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Radoslaw Rodak
In reply to this post by David Lloyd-2
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 <[hidden email]>:

> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Radoslaw Rodak
In reply to this post by Bill Burke

Am 28.02.2013 um 22:05 schrieb Bill Burke <[hidden email]>:


For example, if I want to turn the current security context into a token
that contains digitally signed identity and permissions, the
aforementioned interfaces don't really have anything defined that allow
me to get at this information.

This is not true :-)
You add your own Principal(s) "yoursprincipal"  to existing principals in Subject.
Principal(s) would contain yours contains digitally signed identity and permissions.

   Subject.getPrincipals().add(yoursprincipal)

This is usually done, by JAAS login Modul  during user authentication ( you can have many at the same time, this is how whole Domain Security works in AS 7 … ) You can have another jass login Modul which just appends authorisation infos similar way...




As far as JAAS goes, the fact that it is completely stateless or backed
by a component model makes it impossible to use even in-VM.  You can't
pre-initialize or pool DB or HTTP connections.  You can pre-load or
initialize keys or other configuration information.


Any authentication inside of AS7 (  this applies also to http logins using valves ) triggers JAAS login… see source code picketbox.

Radek Rodak


On 2/28/2013 1: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!


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Radoslaw Rodak
In reply to this post by David Lloyd-2
I forgot to mension, securit propagation with JAAS works allready with EAP6 between stand alone ejb-client and AS 7.1.2 Server….

https://access.redhat.com/support/cases/00698534

Radek Rodak



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

David Lloyd-2
In reply to this post by Bill Burke
I think it's fair to say that a security token could be counted as a
"credential".  That's what I was envisioning for EJB remote invocation
in any case.  As long as the credential type is public you can easily
access them using the typed get*Credentials() methods on Subject; same
for typed Principals.  It seems to me that roles could just as well be
Principals as well (in fact I think they are already modeled this way,
at least in some places), and so if they're mapped on to the Subject and
we use Subject.doAs to implement run-as, then isCallerInRole could be as
easy as Subject.getPrincipals().contians(xx) - though I would have to
read the code again to ensure that there aren't any security issues
there (shouldn't be as long as the Subject is read-only).

For JAAS I am not condoning using it beyond its capabilities, but with
(for example) EJB remote auth, the API would end up looking really a lot
like LoginContext anyway from our design discussions in Brno.  If the
API fits, might as well use it.

I think to round out Subject as a uniform security context, regardless
of whether we end up using ACC to propagate it, we need to better define
how different types of credentials and tokens are (or are not) cached in
it, and how they are accessed.  Existing use cases and examples are
invaluable here.

On 02/28/2013 03:05 PM, Bill Burke wrote:

> First of all, IIRC, all the EE components already have a unified
> security context.  Servlet, EJB, JCA.  (Not sure about HornetQ).  And
> you could propagate the security context from the servlet tier all the
> way to your database in one call stack.  These already build off of
> Principal and Subject as Anil said...but...
>
> You can build off of Principal, Subject, and ACC, but you'll still need
> to define how permissions/role mappings can be created as well as
> introspected..  As a protocol developer, I can't really do much with a
> Principal and Subject and ACC without knowing how populate a Subject
> with metadata or knowing how to extract specific metadata from it.  The
> interfaces you mention are just too generic and targeted specifically to
> check permissions.
>
> For example, if I want to turn the current security context into a token
> that contains digitally signed identity and permissions, the
> aforementioned interfaces don't really have anything defined that allow
> me to get at this information.
>
> As far as JAAS goes, the fact that it is completely stateless or backed
> by a component model makes it impossible to use even in-VM.  You can't
> pre-initialize or pool DB or HTTP connections.  You can pre-load or
> initialize keys or other configuration information.
>
>
> On 2/28/2013 1: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!
>>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

David Lloyd-2
In reply to this post by Radoslaw Rodak
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 <[hidden email]>:
>
>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>> --
>> - DML
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Bill Burke
In reply to this post by David Lloyd-2


On 2/28/2013 5:53 PM, David M. Lloyd wrote:

> I think it's fair to say that a security token could be counted as a
> "credential".  That's what I was envisioning for EJB remote invocation
> in any case.  As long as the credential type is public you can easily
> access them using the typed get*Credentials() methods on Subject; same
> for typed Principals.It seems to me that roles could just as well be
> Principals as well (in fact I think they are already modeled this way,
> at least in some places), and so if they're mapped on to the Subject and
> we use Subject.doAs to implement run-as, then isCallerInRole could be as
> easy as Subject.getPrincipals().contians(xx) - though I would have to
> read the code again to ensure that there aren't any security issues
> there (shouldn't be as long as the Subject is read-only).
>

A security token is a credential, but it may have permission and role
mappings within it.  Server receives the bearer token, verifies the
signature, creates a Principal from the identity stored in the token,
extracts role mappings from the token and associates it with the
Subject.  The role mapping association is the API I'm talking about.
(BTW, this type of protocol allows services to not have to ping a
central auth server.  All they need is a public key to verify signatures)

Then you have the case of propagation.  Lets say you have an RMI EJB
invocation that needs to communicate securely with a RESTful service
that uses this smart bearer token protocol.  Then you'll have to create
a smart token with identity and permission and role mapping metadata
that's stored within the Subject.

BTW, I was wrong, this API does exist in the Picketlink Security Context
(its just hidden and made useless by all the shit layers in JBossWeb).

SecurityContexxt.getUtil();
org.jboss.security.SecurityContextUtil

Whether or not you want to re-use what exists in Picketlink is
orthogonal, but I personally need an API like SecurityContextUtil.
Anybody doing their own custom security will probably want this API as well.

> For JAAS I am not condoning using it beyond its capabilities, but with
> (for example) EJB remote auth, the API would end up looking really a lot
> like LoginContext anyway from our design discussions in Brno.  If the
> API fits, might as well use it.
>

To hell with JAAS.  Deprecate and eliminate that junk.

Again, LoginModules are stateless and have no component injection model
and there's no way to cache, lookup, or initialize global state other
than static variables.

Take a look at how we implement JDBC or LDAP LoginModule.  There is no
caching done, so each and every time you execute these it results in a
database or LDAP remote invocation.  Not very scalable for something
like Basic Auth, or even EJB that re-auths every request.  So...then you
have the AuthenticationManager which was layered on top of JAAS so it
can cache verified credentials.  Great for username and password.  But
what about something as simple as OTP where it is impossible to cache
and re-verify the credential as its different every time?

What about multi-challenge protocols that Darren wants to implement?  Or
protocols you'll need to hold state in between requests, like OAuth?
JAAS is totally useless here.  Just give me a reference to the Identity
Store and a filter/interceptor model at my protocol layer.  JAAS just
gets in the way.  It sucks.  Deprecate it. Banish it to hell.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Anil Saldhana
In reply to this post by David Lloyd-2
On 02/28/2013 05:18 PM, David M. Lloyd wrote:

> 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.
I dont think I have ever supported sending Subjects over the wire. The
Subject is a local VM representation. It is better to send a SAML Assertion
which does not contain a credential but closer to a Principal. The only
difference
here is the SAML Assertion needs to be validated by an IDP/STS within a
small time
period. If you do not like a SAML Assertion, it can be some other token
- OAuth
or a custom binary token.

>
> 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 <[hidden email]>:
>>
>>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Anil Saldhana
In reply to this post by Bill Burke
On 02/28/2013 06:30 PM, Bill Burke wrote:

>
> On 2/28/2013 5:53 PM, David M. Lloyd wrote:
>> I think it's fair to say that a security token could be counted as a
>> "credential".  That's what I was envisioning for EJB remote invocation
>> in any case.  As long as the credential type is public you can easily
>> access them using the typed get*Credentials() methods on Subject; same
>> for typed Principals.It seems to me that roles could just as well be
>> Principals as well (in fact I think they are already modeled this way,
>> at least in some places), and so if they're mapped on to the Subject and
>> we use Subject.doAs to implement run-as, then isCallerInRole could be as
>> easy as Subject.getPrincipals().contians(xx) - though I would have to
>> read the code again to ensure that there aren't any security issues
>> there (shouldn't be as long as the Subject is read-only).
>>
> A security token is a credential, but it may have permission and role
> mappings within it.  Server receives the bearer token, verifies the
> signature, creates a Principal from the identity stored in the token,
> extracts role mappings from the token and associates it with the
> Subject.  The role mapping association is the API I'm talking about.
> (BTW, this type of protocol allows services to not have to ping a
> central auth server.  All they need is a public key to verify signatures)
>
> Then you have the case of propagation.  Lets say you have an RMI EJB
> invocation that needs to communicate securely with a RESTful service
> that uses this smart bearer token protocol.  Then you'll have to create
> a smart token with identity and permission and role mapping metadata
> that's stored within the Subject.
>
> BTW, I was wrong, this API does exist in the Picketlink Security Context
> (its just hidden and made useless by all the shit layers in JBossWeb).
>
> SecurityContexxt.getUtil();
> org.jboss.security.SecurityContextUtil
>
> Whether or not you want to re-use what exists in Picketlink is
> orthogonal, but I personally need an API like SecurityContextUtil.
> Anybody doing their own custom security will probably want this API as well.
SecurityContext was supposed to be our primary API. I just put all the
extra methods operating
on the SC inside an util class.

What Bill is referring to is here:
http://anonsvn.jboss.org/repos/picketbox/trunk/security-spi/spi/src/main/java/org/jboss/security/SecurityContext.java
http://anonsvn.jboss.org/repos/picketbox/trunk/security-spi/spi/src/main/java/org/jboss/security/SecurityContextUtil.java

>
>> For JAAS I am not condoning using it beyond its capabilities, but with
>> (for example) EJB remote auth, the API would end up looking really a lot
>> like LoginContext anyway from our design discussions in Brno.  If the
>> API fits, might as well use it.
>>
> To hell with JAAS.  Deprecate and eliminate that junk.
>
> Again, LoginModules are stateless and have no component injection model
> and there's no way to cache, lookup, or initialize global state other
> than static variables.
>
> Take a look at how we implement JDBC or LDAP LoginModule.  There is no
> caching done, so each and every time you execute these it results in a
> database or LDAP remote invocation.  Not very scalable for something
> like Basic Auth, or even EJB that re-auths every request.  So...then you
> have the AuthenticationManager which was layered on top of JAAS so it
> can cache verified credentials.  Great for username and password.  But
> what about something as simple as OTP where it is impossible to cache
> and re-verify the credential as its different every time?
>
> What about multi-challenge protocols that Darren wants to implement?  Or
> protocols you'll need to hold state in between requests, like OAuth?
> JAAS is totally useless here.  Just give me a reference to the Identity
> Store and a filter/interceptor model at my protocol layer.  JAAS just
> gets in the way.  It sucks.  Deprecate it. Banish it to hell.
>
The plan is to deprecate JAAS in AS8+  and bring in an IDM driven
authentication if possible.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Darran Lofthouse
In reply to this post by Bill Burke
(Sorry this has turned into a longer reply but after reading the thread
I am only replying once ;-) )

>> For JAAS I am not condoning using it beyond its capabilities, but with
>> (for example) EJB remote auth, the API would end up looking really a lot
>> like LoginContext anyway from our design discussions in Brno.  If the
>> API fits, might as well use it.

Yes when you look at the JAAS API it is a client side API and not a
server side API - this is easily seen as a CallbakHandler is passed in
to the LoginContext and then LoginModules to allow Callbacks to be
passed back for interaction with the client.

Within AS what we currently have is a wrapper around this client API for
use within a server - when dealing with a limited set of simple use
cases to be fair this wrapper worked well.  However once you start to
try and move beyond this you quickly hit the limits and end up with
workaround after workaround.

If however we are talking about using the JAAS API client side for the
purpose of obtaining the tokens we were talking about with the new
authentication service and having available a populated Subject that we
can use with a doAs to specify the user a request should be run as
subsequently then yes I would say the API is a very good fit.

As an example we currently use the Krb5LoginModule with a JAAS
LoginContext to obtain a Kerberos token, when we need to perform tasks
as that user we make use of the populated Subject with a doAs -
potentially we can have multiple tokens by having multiple populated
Subjects and switch between them by choosing whichever one is most
appropriate.

So for the authentication service providing a LoginModule on the client
side could make a lot of sense, combined with CallbackHandlers and a bit
of configuration this same implementation would be compatible with the
fully authenticated switching of identities and also switching based on
trust.

To continue on that slightly I know it has been raised elsewhere on this
thread but as I am replying here.  I don't think anyone is now
advocating propagating a full Subject from server to server and I agree
- the safer option is for the client side of a call to request that the
server side of a call runs the request as a specific user, a trust
decision is made to see if that is allowed and then the identity of the
run as user is loaded server side - so no sneaking in additional roles ;-)

This architecture would also be suitable for authentication mechanisms
that have support for identity propagation built in e.g. using this we
could do client to server to server and propagate a Kerberos identity
along the whole call chain.

> To hell with JAAS.  Deprecate and eliminate that junk.
>
> Again, LoginModules are stateless and have no component injection model
> and there's no way to cache, lookup, or initialize global state other
> than static variables.
>
> Take a look at how we implement JDBC or LDAP LoginModule.  There is no
> caching done, so each and every time you execute these it results in a
> database or LDAP remote invocation.  Not very scalable for something
> like Basic Auth, or even EJB that re-auths every request.  So...then you
> have the AuthenticationManager which was layered on top of JAAS so it
> can cache verified credentials.  Great for username and password.  But
> what about something as simple as OTP where it is impossible to cache
> and re-verify the credential as its different every time?

Yes this is exactly why using JAAS server side has reached it's limit.
Everything is based around the assumption that we have a static
username/credential pair that is the same for every request which is not
true for many authentication mechanisms.

Switching to an IDM based approached it will be the IDM's responsibility
to cache interaction with the remote store instead of the current
approach of caching successful authentication attempts - that way
authentication can occur per request without necessarily having to hit
the store for each request.

> What about multi-challenge protocols that Darren wants to implement?  Or
> protocols you'll need to hold state in between requests, like OAuth?
> JAAS is totally useless here.  Just give me a reference to the Identity
> Store and a filter/interceptor model at my protocol layer.  JAAS just
> gets in the way.  It sucks.  Deprecate it. Banish it to hell.

Server side I don't think anyone is currently advocating JAAS and
neither am I ;-)

However a JAAS LoginModule client side combined with a CallbackHandler I
think would be suited to multi-challenge authentication protocols for
the purpose of something along the lines of an authentication service we
previously discussed for switching identities for remote calls.

>

For the rest of this discussion using JAAS server side it not a
pre-requisite to being able to use a Subject - in fact even the current
domain management realms sparsely populate a Subject today without using
JAAS.

So for entry to the server making use of HTTP and SASL based
authentication backed by an IDM instead of JAAS and then converting the
loaded identity into a Subject does sound good.

One point to keep in mind that is different from the JAAS population of
Subjects however is that the IDM approach is not currently expecting to
load roles pro-actively for an identity, instead it is expecting to
respond to isCallerInRole type checks as and when role checks are
required.  Applications however do have a finite set of roles used so
there are options here.

Regards,
Darran Lofthouse.
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Anil Saldhana
I created this dashboard to track all the security related discussions
with AS8++
https://community.jboss.org/wiki/JBossAS8SecurityDashboard


On 03/01/2013 05:22 AM, Darran Lofthouse wrote:

> (Sorry this has turned into a longer reply but after reading the thread
> I am only replying once ;-) )
>
>>> For JAAS I am not condoning using it beyond its capabilities, but with
>>> (for example) EJB remote auth, the API would end up looking really a lot
>>> like LoginContext anyway from our design discussions in Brno.  If the
>>> API fits, might as well use it.
> Yes when you look at the JAAS API it is a client side API and not a
> server side API - this is easily seen as a CallbakHandler is passed in
> to the LoginContext and then LoginModules to allow Callbacks to be
> passed back for interaction with the client.
>
> Within AS what we currently have is a wrapper around this client API for
> use within a server - when dealing with a limited set of simple use
> cases to be fair this wrapper worked well.  However once you start to
> try and move beyond this you quickly hit the limits and end up with
> workaround after workaround.
>
> If however we are talking about using the JAAS API client side for the
> purpose of obtaining the tokens we were talking about with the new
> authentication service and having available a populated Subject that we
> can use with a doAs to specify the user a request should be run as
> subsequently then yes I would say the API is a very good fit.
>
> As an example we currently use the Krb5LoginModule with a JAAS
> LoginContext to obtain a Kerberos token, when we need to perform tasks
> as that user we make use of the populated Subject with a doAs -
> potentially we can have multiple tokens by having multiple populated
> Subjects and switch between them by choosing whichever one is most
> appropriate.
>
> So for the authentication service providing a LoginModule on the client
> side could make a lot of sense, combined with CallbackHandlers and a bit
> of configuration this same implementation would be compatible with the
> fully authenticated switching of identities and also switching based on
> trust.
>
> To continue on that slightly I know it has been raised elsewhere on this
> thread but as I am replying here.  I don't think anyone is now
> advocating propagating a full Subject from server to server and I agree
> - the safer option is for the client side of a call to request that the
> server side of a call runs the request as a specific user, a trust
> decision is made to see if that is allowed and then the identity of the
> run as user is loaded server side - so no sneaking in additional roles ;-)
>
> This architecture would also be suitable for authentication mechanisms
> that have support for identity propagation built in e.g. using this we
> could do client to server to server and propagate a Kerberos identity
> along the whole call chain.
>
>> To hell with JAAS.  Deprecate and eliminate that junk.
>>
>> Again, LoginModules are stateless and have no component injection model
>> and there's no way to cache, lookup, or initialize global state other
>> than static variables.
>>
>> Take a look at how we implement JDBC or LDAP LoginModule.  There is no
>> caching done, so each and every time you execute these it results in a
>> database or LDAP remote invocation.  Not very scalable for something
>> like Basic Auth, or even EJB that re-auths every request.  So...then you
>> have the AuthenticationManager which was layered on top of JAAS so it
>> can cache verified credentials.  Great for username and password.  But
>> what about something as simple as OTP where it is impossible to cache
>> and re-verify the credential as its different every time?
> Yes this is exactly why using JAAS server side has reached it's limit.
> Everything is based around the assumption that we have a static
> username/credential pair that is the same for every request which is not
> true for many authentication mechanisms.
>
> Switching to an IDM based approached it will be the IDM's responsibility
> to cache interaction with the remote store instead of the current
> approach of caching successful authentication attempts - that way
> authentication can occur per request without necessarily having to hit
> the store for each request.
>
>> What about multi-challenge protocols that Darren wants to implement?  Or
>> protocols you'll need to hold state in between requests, like OAuth?
>> JAAS is totally useless here.  Just give me a reference to the Identity
>> Store and a filter/interceptor model at my protocol layer.  JAAS just
>> gets in the way.  It sucks.  Deprecate it. Banish it to hell.
> Server side I don't think anyone is currently advocating JAAS and
> neither am I ;-)
>
> However a JAAS LoginModule client side combined with a CallbackHandler I
> think would be suited to multi-challenge authentication protocols for
> the purpose of something along the lines of an authentication service we
> previously discussed for switching identities for remote calls.
>
> For the rest of this discussion using JAAS server side it not a
> pre-requisite to being able to use a Subject - in fact even the current
> domain management realms sparsely populate a Subject today without using
> JAAS.
>
> So for entry to the server making use of HTTP and SASL based
> authentication backed by an IDM instead of JAAS and then converting the
> loaded identity into a Subject does sound good.
>
> One point to keep in mind that is different from the JAAS population of
> Subjects however is that the IDM approach is not currently expecting to
> load roles pro-actively for an identity, instead it is expecting to
> respond to isCallerInRole type checks as and when role checks are
> required.  Applications however do have a finite set of roles used so
> there are options here.
>
> Regards,
> Darran Lofthouse.
> _____________________
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Bill Burke
In reply to this post by Darran Lofthouse


On 3/1/2013 6:22 AM, Darran Lofthouse wrote:

> So for entry to the server making use of HTTP and SASL based
> authentication backed by an IDM instead of JAAS and then converting the
> loaded identity into a Subject does sound good.
>
> One point to keep in mind that is different from the JAAS population of
> Subjects however is that the IDM approach is not currently expecting to
> load roles pro-actively for an identity, instead it is expecting to
> respond to isCallerInRole type checks as and when role checks are
> required.  Applications however do have a finite set of roles used so
> there are options here.
>

Not sure what you're saying here, but the IDM API needs to be able to do
more than isCallerInRole().  See my previous examples.


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

David Lloyd-2
On 03/01/2013 01:10 PM, Bill Burke wrote:

>
>
> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>> So for entry to the server making use of HTTP and SASL based
>> authentication backed by an IDM instead of JAAS and then converting the
>> loaded identity into a Subject does sound good.
>>
>> One point to keep in mind that is different from the JAAS population of
>> Subjects however is that the IDM approach is not currently expecting to
>> load roles pro-actively for an identity, instead it is expecting to
>> respond to isCallerInRole type checks as and when role checks are
>> required.  Applications however do have a finite set of roles used so
>> there are options here.
>>
>
> Not sure what you're saying here, but the IDM API needs to be able to do
> more than isCallerInRole().  See my previous examples.

I think that the next step in exploring this idea would be to figure out
exactly what this would mean - how to integrate with, or replicate, our
existing IDM API(s), what we need to be able to store on/get out of the
security context itself - basically start with use cases and move on to
requirements from there.

Bill had good examples of propagating bearer tokens between EJB and REST
or other services, and I think he's asking the right questions.  Keeping
in mind (and leaving aside) that this may or may not be appropriate for
AS 8, what other use cases and requirements are there for the security
context itself?
--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Bill Burke


On 3/4/2013 12:16 PM, David M. Lloyd wrote:

> On 03/01/2013 01:10 PM, Bill Burke wrote:
>>
>>
>> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>>> So for entry to the server making use of HTTP and SASL based
>>> authentication backed by an IDM instead of JAAS and then converting the
>>> loaded identity into a Subject does sound good.
>>>
>>> One point to keep in mind that is different from the JAAS population of
>>> Subjects however is that the IDM approach is not currently expecting to
>>> load roles pro-actively for an identity, instead it is expecting to
>>> respond to isCallerInRole type checks as and when role checks are
>>> required.  Applications however do have a finite set of roles used so
>>> there are options here.
>>>
>>
>> Not sure what you're saying here, but the IDM API needs to be able to do
>> more than isCallerInRole().  See my previous examples.
>
> I think that the next step in exploring this idea would be to figure out
> exactly what this would mean - how to integrate with, or replicate, our
> existing IDM API(s), what we need to be able to store on/get out of the
> security context itself - basically start with use cases and move on to
> requirements from there.
>
> Bill had good examples of propagating bearer tokens between EJB and REST
> or other services, and I think he's asking the right questions.  Keeping
> in mind (and leaving aside) that this may or may not be appropriate for
> AS 8, what other use cases and requirements are there for the security
> context itself?
>

I don't understand why you'd even consider taking a step backwards.  The
AS7 SecurityContext (via Picketlink) already has the ability to get and
set role mappings and permissions.  This provides a large measure of
flexibility and allows developers to implement custom security protocols
through standard components i.e. servlet filters.  The IDM API should be
for fetching security metadata, thats it.  I don't see why you'd want
the IDM API to be anything more than that.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

David Lloyd-2
On 03/04/2013 12:32 PM, Bill Burke wrote:

>
>
> On 3/4/2013 12:16 PM, David M. Lloyd wrote:
>> On 03/01/2013 01:10 PM, Bill Burke wrote:
>>>
>>>
>>> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>>>> So for entry to the server making use of HTTP and SASL based
>>>> authentication backed by an IDM instead of JAAS and then converting the
>>>> loaded identity into a Subject does sound good.
>>>>
>>>> One point to keep in mind that is different from the JAAS population of
>>>> Subjects however is that the IDM approach is not currently expecting to
>>>> load roles pro-actively for an identity, instead it is expecting to
>>>> respond to isCallerInRole type checks as and when role checks are
>>>> required.  Applications however do have a finite set of roles used so
>>>> there are options here.
>>>>
>>>
>>> Not sure what you're saying here, but the IDM API needs to be able to do
>>> more than isCallerInRole().  See my previous examples.
>>
>> I think that the next step in exploring this idea would be to figure out
>> exactly what this would mean - how to integrate with, or replicate, our
>> existing IDM API(s), what we need to be able to store on/get out of the
>> security context itself - basically start with use cases and move on to
>> requirements from there.
>>
>> Bill had good examples of propagating bearer tokens between EJB and REST
>> or other services, and I think he's asking the right questions.  Keeping
>> in mind (and leaving aside) that this may or may not be appropriate for
>> AS 8, what other use cases and requirements are there for the security
>> context itself?
>>
>
> I don't understand why you'd even consider taking a step backwards.  The
> AS7 SecurityContext (via Picketlink) already has the ability to get and
> set role mappings and permissions.  This provides a large measure of
> flexibility and allows developers to implement custom security protocols
> through standard components i.e. servlet filters.  The IDM API should be
> for fetching security metadata, thats it.  I don't see why you'd want
> the IDM API to be anything more than that.

All I'm basically talking about is replacing SecurityContext's internal
mechanism with the JDK AccessControlContext; that's really it.  The
question is really about how to replace the stuff that was previously
internally stored on the thread local (and the thread locals of other
projects that reinvent this particular wheel), and the range of possible
answers isn't that huge: it amounts to using the Subject's private data
fields in various ways.

We need to do this if we want to support Subject.doAs() in some
consistent manner (a bunch of frameworks we consume already use this, so
the state of our security integration - especially with an SM present -
can only be described as "spotty and weird").  It also makes integration
easier (especially with these frameworks) for the reasons I laid out in
my original email, and works nicely with the new SecurityManager
requirements in EE7.

The fact is, the way we manage security context is weird and ad-hoc
without any good reason for being that way.  Because of this we end up
paying a cost in memory usage and performance, not to mention the
leaking security context bugs that crop up from time to time.  Anil
pointed out that even Scott wanted to change over to support
Subject.doAs(), but never quite got around to it.

The desirable end state would be to either be able to use the same APIs
(or at worst, equivalent APIs) that we had before.  But without
understanding how they're used today we'll just end up running into
trouble.  There's never any downside to gathering information, in any case.

--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Bill Burke


On 3/4/2013 2:17 PM, David M. Lloyd wrote:

> On 03/04/2013 12:32 PM, Bill Burke wrote:
>>
>>
>> On 3/4/2013 12:16 PM, David M. Lloyd wrote:
>>> On 03/01/2013 01:10 PM, Bill Burke wrote:
>>>>
>>>>
>>>> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>>>>> So for entry to the server making use of HTTP and SASL based
>>>>> authentication backed by an IDM instead of JAAS and then converting the
>>>>> loaded identity into a Subject does sound good.
>>>>>
>>>>> One point to keep in mind that is different from the JAAS population of
>>>>> Subjects however is that the IDM approach is not currently expecting to
>>>>> load roles pro-actively for an identity, instead it is expecting to
>>>>> respond to isCallerInRole type checks as and when role checks are
>>>>> required.  Applications however do have a finite set of roles used so
>>>>> there are options here.
>>>>>
>>>>
>>>> Not sure what you're saying here, but the IDM API needs to be able to do
>>>> more than isCallerInRole().  See my previous examples.
>>>
>>> I think that the next step in exploring this idea would be to figure out
>>> exactly what this would mean - how to integrate with, or replicate, our
>>> existing IDM API(s), what we need to be able to store on/get out of the
>>> security context itself - basically start with use cases and move on to
>>> requirements from there.
>>>
>>> Bill had good examples of propagating bearer tokens between EJB and REST
>>> or other services, and I think he's asking the right questions.  Keeping
>>> in mind (and leaving aside) that this may or may not be appropriate for
>>> AS 8, what other use cases and requirements are there for the security
>>> context itself?
>>>
>>
>> I don't understand why you'd even consider taking a step backwards.  The
>> AS7 SecurityContext (via Picketlink) already has the ability to get and
>> set role mappings and permissions.  This provides a large measure of
>> flexibility and allows developers to implement custom security protocols
>> through standard components i.e. servlet filters.  The IDM API should be
>> for fetching security metadata, thats it.  I don't see why you'd want
>> the IDM API to be anything more than that.
>
> All I'm basically talking about is replacing SecurityContext's internal
> mechanism with the JDK AccessControlContext; that's really it.

And all I'm saying is that ACC, as-is, is an incomplete API for our
needs.  If you can extend this class, great.  From what you're saying,
it sounds like using ACC would solve a few integration problems.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: On security context and propagation

Anil Saldhana
On 03/04/2013 01:30 PM, Bill Burke wrote:

>
> On 3/4/2013 2:17 PM, David M. Lloyd wrote:
>> On 03/04/2013 12:32 PM, Bill Burke wrote:
>>>
>>> On 3/4/2013 12:16 PM, David M. Lloyd wrote:
>>>> On 03/01/2013 01:10 PM, Bill Burke wrote:
>>>>>
>>>>> On 3/1/2013 6:22 AM, Darran Lofthouse wrote:
>>>>>> So for entry to the server making use of HTTP and SASL based
>>>>>> authentication backed by an IDM instead of JAAS and then converting the
>>>>>> loaded identity into a Subject does sound good.
>>>>>>
>>>>>> One point to keep in mind that is different from the JAAS population of
>>>>>> Subjects however is that the IDM approach is not currently expecting to
>>>>>> load roles pro-actively for an identity, instead it is expecting to
>>>>>> respond to isCallerInRole type checks as and when role checks are
>>>>>> required.  Applications however do have a finite set of roles used so
>>>>>> there are options here.
>>>>>>
>>>>> Not sure what you're saying here, but the IDM API needs to be able to do
>>>>> more than isCallerInRole().  See my previous examples.
>>>> I think that the next step in exploring this idea would be to figure out
>>>> exactly what this would mean - how to integrate with, or replicate, our
>>>> existing IDM API(s), what we need to be able to store on/get out of the
>>>> security context itself - basically start with use cases and move on to
>>>> requirements from there.
>>>>
>>>> Bill had good examples of propagating bearer tokens between EJB and REST
>>>> or other services, and I think he's asking the right questions.  Keeping
>>>> in mind (and leaving aside) that this may or may not be appropriate for
>>>> AS 8, what other use cases and requirements are there for the security
>>>> context itself?
>>>>
>>> I don't understand why you'd even consider taking a step backwards.  The
>>> AS7 SecurityContext (via Picketlink) already has the ability to get and
>>> set role mappings and permissions.  This provides a large measure of
>>> flexibility and allows developers to implement custom security protocols
>>> through standard components i.e. servlet filters.  The IDM API should be
>>> for fetching security metadata, thats it.  I don't see why you'd want
>>> the IDM API to be anything more than that.
>> All I'm basically talking about is replacing SecurityContext's internal
>> mechanism with the JDK AccessControlContext; that's really it.
> And all I'm saying is that ACC, as-is, is an incomplete API for our
> needs.  If you can extend this class, great.  From what you're saying,
> it sounds like using ACC would solve a few integration problems.
>
ACC is useful for threaded applications.  It works on a single thread -
end to end.  If our
use cases are from client - ejb-rest  on a single thread, it works.  But
if you desire
to have a generic security context api that may be session based in
addition to thread model,  ACC does not work.

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12