[jboss-jira] [JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC
arjan tijms (JIRA)
issues at jboss.org
Wed Jul 13 18:46:00 EDT 2016
[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265403#comment-13265403 ]
arjan tijms commented on WFLY-5739:
-----------------------------------
{quote}I have just sent PR https://github.com/wildfly/wildfly/pull/9003 that fixes it (for me){quote}
I think you meant https://github.com/wildfly/wildfly/pull/9030 ;)
I checked the latest change and it looks quite good, but I must say I'm also not the WildFly internals specialist. But indeed, because registerSession is handled in the {{AuthenticationMechanism}}, it makes much more sense that the handler only uses one approach to set the groups/roles data, and then the mechanism copies this to all other places.
Perhaps it would be even cleaner if the handler only stored the raw data as set by the SAM via the callbacks in a private simple TLS variable, and then let the authentication mechanism install that in the 3 places you identified (i.e. including {{JbossSecurityContext}}). Now there may be the small weirdness that after calling the handler, but before returning from {{validateRequest}} the caller is sort of partially authenticated. But alas, that's unrelated to this particular PR.
Those 3 places to store the authentication data have been a frequent source of bugs. More than a handful of previous bugs has been related to those 3 not being kept in perfect sync. (This is incidentally also why for JSR 375 I really didn't want to introduce a JSR 375 specific place to store this same data, as it would mean yet another location that can get out of sync with whatever the container is using.)
I would like to thank the both of you again for helping out with these issues. Great work ;)
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-5739
> URL: https://issues.jboss.org/browse/WFLY-5739
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Labels: jacc, jaspic
> Attachments: CustomAuth.zip, picketbox.zip
>
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list