<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 28.02.2013 um 22:05 schrieb Bill Burke <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>:</div><br><blockquote type="cite"><br>For example, if I want to turn the current security context into a token <br>that contains digitally signed identity and permissions, the <br>aforementioned interfaces don't really have anything defined that allow <br>me to get at this information.<br></blockquote><div><br></div><div>This is not true :-)</div><div>You add your own Principal(s) "<span style="background-color: rgb(255, 255, 255); color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12px; line-height: 16px; ">yoursprincipal" </span> to existing principals in Subject.</div><div>Principal(s) would contain yours contains digitally signed identity and permissions.</div><div><br></div><div><span style="background-color: rgb(255, 255, 255); "> </span><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; line-height: 16px; background-color: rgb(255, 255, 255); ">Subject</span><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12px; line-height: 16px; background-color: rgb(255, 255, 255); ">.</span><em style="font-weight: bold; font-style: normal; font-family: arial, sans-serif; font-size: 12px; line-height: 16px; background-color: rgb(255, 255, 255); ">getPrincipals</em><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12px; line-height: 16px; background-color: rgb(255, 255, 255); ">().</span><em style="font-weight: bold; font-style: normal; font-family: arial, sans-serif; font-size: 12px; line-height: 16px; background-color: rgb(255, 255, 255); ">add</em><span style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 12px; line-height: 16px; background-color: rgb(255, 255, 255); ">(yoursprincipal)</span></div><div><br></div><div>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...</div><div><br></div><div><br></div><br><blockquote type="cite"><br>As far as JAAS goes, the fact that it is completely stateless or backed <br>by a component model makes it impossible to use even in-VM. You can't <br>pre-initialize or pool DB or HTTP connections. You can pre-load or <br>initialize keys or other configuration information.<br><br></blockquote><div><br></div><div>Any authentication inside of AS7 ( this applies also to http logins using valves ) triggers JAAS login… see source code picketbox.</div><div><br></div><div>Radek Rodak</div><br><blockquote type="cite"><br>On 2/28/2013 1:30 PM, David M. Lloyd wrote:<br><blockquote type="cite">The Problem<br>===========<br>In order to support all the Java EE 7 requirements, we need to be able<br>to propagate security context in a predictable and uniform manner.<br>Unfortunately, we have almost as many security context concepts as we do<br>projects which support authentication. There is no single way to<br>execute a task given a security context snapshot from another thread<br>that will work for all of our projects.<br><br>Project-Specific Security Context<br>---------------------------------<br>The typical implementation of a project-specific security context is<br>just a Subject, cached into a ThreadLocal and available via some<br>accessors. In addition we have the SecurityRolesAssociation concept<br>from PicketBox, which is meant to encapsulate roles from an EE perspective.<br><br>Available Mechanisms<br>====================<br>A number of mechanisms are provided by the JDK and the EE SDK<br>specifically for addressing this problem domain. Here's a quick review<br>so we are all speaking the same language.<br><br>javax.security.auth.Subject<br>---------------------------<br>The focal point for security in both SE and EE is the Subject class,<br>which is an encapsulation of related information for a security entity,<br>including credentials (passwords, keys, etc.) and identities (user/group<br>names, roles, etc.). Most (not all) of our security-aware projects<br>already seem to use Subject, though they may not all be using it in the<br>same way.<br><br>Subject has some utility methods which are intended to allow association<br>with the current security context. With these methods you can run tasks<br>as different Subjects. We currently do not support these methods.<br><br>java.security.Principal<br>-----------------------<br>The base interface for an identity. Though there are no specific<br>supported implementations for EE use cases, this interface would be the<br>base for user names, group names, role names, and so on. JDK Principal<br>implementations do exist for filesystem users and groups, certificate<br>signers and principals, JMX authenticated identities, etc.<br><br>java.security.AccessControlContext ("ACC")<br>------------------------------------------<br>This is *the* JDK-provided security context. It represents the<br>accumulated privileges of "protection domains", which can in turn<br>correspond to principals, permissions, and/or code sources (i.e. JARs).<br> A given ACC, in simplified terms, represents the *intersection* of<br>privileges granted by all the invocations on the call stack.<br><br>It gets a bit complex once you plumb the depths but imagine ACC<br>conceptually like a second execution stack. Every time you call into<br>another module, you push another layer on the stack which includes that<br>module's permission set (which is AllPermission by default, but can be<br>restricted on a per-module basis). This also includes calling into<br>deployments. You can also push a Subject on to this stack using<br>Subject.doAs*().<br><br>It is worth emphasizing that the effective permission set for an ACC is<br>the intersection of all of its parts, so the more calls you make, the<br>more restricted your permissions are. This is why we use<br>AccessController.doPrivileged*() and/or Subject.doAsPrivileged(): it<br>"clears" the stack for the duration of the invocation, adding only the<br>module which hosts the Privileged*Action class being executed (and<br>optionally the given Subject as well). This becomes important when you<br>consider that in many cases, you have no idea under what context a given<br>piece of code will be run, thus you cannot be certain whether a<br>restricted operation will succeed without using doPrivileged().<br><br>Perhaps the canonical case of this is class initialization. Common<br>sense would seem to imply that classes should always be initialized in a<br>privileged context, but that does not seem to be the case in reality.<br>Thus class init is often stuck with awkward doPrivileged constructs,<br>especially when field init is involved.<br><br>A Unified Security Context<br>==========================<br>The ACC affords us a uniquely suited mechanism for security association.<br> Subjects are already designed to be connected into ACCs; in fact, you<br>can query an ACC for its associated Subject with a simple get. In turn<br>the Subject can be queried for its Principals and credentials.<br><br>This also gives us saner integration with JAAS, to the extent that such<br>sanity is possible; users can use the returned Subject with<br>Subject.doAs() and get the results they would expect in any situation.<br><br>Finally ACC is in the JDK - any third-party security-aware framework is<br>much more likely to integrate with ACC and Subject than with some<br>framework provided by us. And, the JDK security manager framework is<br>ready to handle it, so a user security policy could for example forbid<br>certain Subjects from performing operations as an additional security layer.<br><br>Getting the Current Subject<br>---------------------------<br>To get the current subject you can do something like this:<br><br> Subject current = Subject.getSubject(AccessController.getContext());<br><br>This will work from any context - though there is a permission check<br>involved so a security action is in order in this case.<br><br>Propagation Within the AS<br>-------------------------<br>We need to do in-system propagation of security context in a few<br>situations. The predominant one (to me) is using JSR-236 thread pools -<br>tasks submitted by an EE component must run under the same security<br>context that the submitter holds.<br><br>Fortunately propagation of this nature is quite simple: use<br>AccessController.getContext() to acquire the current security context,<br>and use AccessController.doPrivileged() to resume.<br><br>Propagation to other components (e.g. EJBs) is a little different<br>though. In this case you do not want the baggage of the caller ACC; you<br>only need to preserve the caller Subject. In this case, you would<br>acquire the Subject as above, and the security interceptor would simply<br>use Subject.doAs() to resume.<br><br>Propagation Over the Network<br>----------------------------<br>It should be possible to use Principal information stored on the Subject<br>in combination with private credentials to provide all the information<br>required for network propagation of security context. This should work<br>particularly well with the Remoting authentication service in particular.<br><br>One Step Farther: ACC-Based Permission Checking<br>-----------------------------------------------<br>It is possible to take this idea a little farther and introduce<br>permission checking for JACC-style permissions based on the ACC. Using<br>ACC.checkPermission we can do permission checking regardless of the<br>presence or absence of a SecurityManager. However, it is not clear what<br>benefits we would derive from this move (if any).<br><br>Costs and Alternatives<br>======================<br>ACC is not free. It's a fairly heavyweight structure (though it does<br>make certain optimizations in some cases), and it contains what is<br>probably more information than is strictly necessary as it is designed<br>for full-bore SecurityManager sandboxing and permission checking. Thus<br>it is worth exploring alternatives.<br><br>Alternative: Central Security Context<br>-------------------------------------<br>Alternative #1 is to support a central security context represented by a<br>Subject in one place which all frameworks and libraries share.<br><br>Pros: lightweight (as much as possible anyway); conceptually simple<br>Cons: not compatible Subject.doAs or AccessController.doPrivileged;<br>additional dependency for all security-aware frameworks; third-party<br>stuff is less likely to just work<br><br>Alternative: ???<br>----------------<br>Add your ideas here!<br><br>Action<br>======<br>I think, barring any major dissent, we should make a move towards using<br>ACC as a unified security context. I think that given the EE 7 security<br>manager requirements and user requests over time, that standardizing<br>around ACC makes sense.<br><br>Discussion: go!<br><br></blockquote><br>-- <br>Bill Burke<br>JBoss, a division of Red Hat<br><a href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>_______________________________________________<br>jboss-as7-dev mailing list<br>jboss-as7-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></blockquote></div><br></body></html>