[ http://jira.jboss.com/jira/browse/JBAS-1438?page=history ]
Scott M Stark closed JBAS-1438:
-------------------------------
Resolution: Done
Fix Version: JBossAS-5.0 Alpha
The security manager and interceptors have been updated to maintain a thread
local stack of the authenticated subject that is pushed and popped on the call
boundaries to ensure that transitions across security domains do not affect the
caller.
+++ Notes on the org.jboss.SecurityAssociation changes:
Two new methods have been added to the SecurityAssociation:
/**
* Push the current authenticated context. This sets the authenticated
subject
* along with the principal and proof of identity that was used to validate
* the subject. This context is used for authorization checks. Typically
* just the subject as seen by getSubject() is input into the authorization.
* When run under a security manager this requires the
*
RuntimePermission("org.jboss.security.SecurityAssociation.setPrincipalInfo")
* permission.
* @param subject - the authenticated subject
* @param principal - the principal that was input into the authentication
* @param credential - the credential that was input into the authentication
*/
public static void pushSubjectContext(Subject subject,
Principal principal, Object credential)
/**
* Pop the current SubjectContext from the previous pushSubjectContext call
* and return the pushed SubjectContext ig there was one.
* When run under a security manager this requires the
*
RuntimePermission("org.jboss.security.SecurityAssociation.setPrincipalInfo")
* permission.
* @return the SubjectContext pushed previously by a pushSubjectContext call
*/
public static SubjectContext popSubjectContext()
These effectively replace the use of setPrincipal, setCredential, setSubject
when running in the server. The setPrincipal, setCredential still have some use
in client vms that are not running in multi-threaded mode(server=false). The
setSubject has no use as it is not used on the client to propagate security
context.
+++ Notes on the JaasSecurityManager changes:
- The isValid(Principal, Object) method no longer sets the SecurityAssociation
Subject as a side effect. This means that interceptors that use isValid to
authenticate a caller need to retrieve the Subject as a byrproduct of the
isValid call. The following pattern:
// Must first validate the user
secManager.isValid(principal, credential);
// Now can query if the authenticated Subject has the role
doesUserHaveRole = realmMapping().doesUserHaveRole(principal, roles);
now requires a pattern like the following:
// Must first validate the user
Subject subject = new Subject();
secManager.isValid(principal, credential, subject);
// Now can query if the authenticated Subject has the role
SecurityAssociation.pushSubjectContext(principal, credential, subject);
doesUserHaveRole = realmMapping().doesUserHaveRole(principal, roles);
...
// Restore the incoming security context
SecurityAssociation.popSubjectContext();
- The doesUserHaveRole(Principal principal, Set rolePrincipals) method no
longer operates on the authentication cache subject. It operates on the
SecurityAssociation Subject and as such requires that the correct Subject has
been installed via the SecurityAssociation.pushSubjectContext as shown above.
Another change that has been true since the 4.0.0 release is that the
doesUserHaveRole result may have no connection to the equivalent role check
done by the ejb or web container if the JACC security service is being used for
authorization. It happens to be true that the current JBoss supplied JACC
implementation leverages the legacy JAAS login module behavior of associating
declarative roles to a user's Subject during authentication, but since JACC is
pluggable, another provider will likely not utilize this behavior. In the
future, alternate JBoss implementations of JACC will also not care about the
Subject Roles and as such the login module behavior will be deprecated and made
an optional aspect.
> EJB isCallerInRole affected by interaction with other secured resources
> -----------------------------------------------------------------------
>
> Key: JBAS-1438
> URL: http://jira.jboss.com/jira/browse/JBAS-1438
> Project: JBoss Application Server
> Type: Bug
> Components: Security, EJBs
> Versions: JBossAS-4.0.1 Final
> Environment: org.jboss.test.jca.test.SecurityContextUnitTestCase
> Reporter: Scott M Stark
> Assignee: Scott M Stark
> Priority: Critical
> Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1
>
>
> On entrace to a secured ejb method the expected roles are seen to be assigned
> to the caller as evidenced by the EJBContext.isCallerInRole(String) method.
> On calling a secured DataSource from within the ejb method, the roles are
> seen to be lost after the DataSource connection has been created.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
