[
https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin....
]
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)