[jboss-jira] [JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC

[István Tóth (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263475#comment-13263475 ] 

István Tóth commented on WFLY-5739:
-----------------------------------

Hello [~ggam]  !
Thank you for your answer and the test case!

After looking at the problem some more, I have come to understand the following:
There are at least three mechansisms/places for storing the group/roles data:
* in JbossSecurityContext (used by most of WildFly, including EJBs)
* in the Subject's ROLES_IDENTIFIER principal (used at least by JACC, and also gets copied to to JbossSecurityContext)
* in the Undertow Account obejct (used by undertow, I guess)

JASPICallbackHandler.java in Picketbox only fills in the JbossSecurityContext. 
JASPICAuthenticationMechanism.java in wildfly copies it to the Account, and optionally caches it.

My original PR tried to fix the JACC roles in picketbox's JASPICallbackHandler.java. However, due to registerSession feature, this bug cannot be fixed in Picketbox alone.

Instead of making essentially the same fix to two projects, I have tried a different approach, and chose to leave picketbox alone, and instead copy the group information to the ROLES_IDENTIFIER principal in wildfly's  JASPICAuthenticationMechanism.java, where the group information is available both during full authentication, and registersession cached authentication.

I am hesitant to turn this into a pull request yet. Could you take a look at https://github.com/stoty/wildfly/commits/WFLY-5739 and tell me if it's a valid approach ? 

> 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)