[
https://issues.jboss.org/browse/WFLY-6579?page=com.atlassian.jira.plugin....
]
arjan tijms updated WFLY-6579:
------------------------------
Description:
When the JASPIC 1.1 register session ({{javax.servlet.http.registerSession}}) is used, the
authenticated identity (via the Subject) is not propagated to the EJB container.
The problems seems to be with {{JASPICAuthenticationMechanism.createAccount}}. When a
cached account is re-used, a {{null}} is passed for the {{Subject}} parameter in the call
to {{jbossSct.getUtil().createSubjectInfo}}. This will set indeed set a {{SubjectInfo}}
with subject being null.
{{EJBContext#getCallerPrincipal}} checks exactly this subject, and when seeing a null will
consider the user to be unauthenticated, even when the caller is authenticated in the web
layer.
See the code below:
{code:java}
// SAM handled the same principal found in the cached account: indicates we must use
the cached account.
if (cachedAccount != null && cachedAccount.getPrincipal() ==
userPrincipal) {
// populate the security context using the cached account data.
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
null); // PROBLEMATIC NULL
RoleGroup roleGroup = new
SimpleRoleGroup(SecurityConstants.ROLES_IDENTIFIER);
for (String role : cachedAccount.getRoles())
roleGroup.addRole(new SimpleRole(role));
jbossSct.getUtil().setRoles(roleGroup);
return cachedAccount;
}
{code}
Instead of passing a {{null}}, passing the existing subject as set by the JASPIC callback
handler seems to work:
{code:java}
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
jbossSct.getUtil().getSubject());
{code}
was:
When the JASPIC 1.1 register session ({{javax.servlet.http.registerSession}}) is used, the
authenticated identity (via the Subject) is not propagated to the EJB container.
The problems seems to be with {{JASPICAuthenticationMechanism.createAccount}}. When a
cached account is re-used, a {{null}} is passed for the {{Subject}} parameter in the call
to {{jbossSct.getUtil().createSubjectInfo}}. This will set indeed set a {{SubjectInfo}}
with subject being null.
{{EJBContext#getCallerPrincipal}} checks exactly this subject, and when seeing a null will
consider the user to be unauthenticated, even when the caller is authenticated in the web
layer.
See the code below:
{code:java}
// SAM handled the same principal found in the cached account: indicates we must use
the cached account.
if (cachedAccount != null && cachedAccount.getPrincipal() ==
userPrincipal) {
// populate the security context using the cached account data.
jbossSct.getUtil().createSubjectInfo(userPrincipal, ((AccountImpl)
cachedAccount).getCredential(), null);
RoleGroup roleGroup = new
SimpleRoleGroup(SecurityConstants.ROLES_IDENTIFIER);
for (String role : cachedAccount.getRoles())
roleGroup.addRole(new SimpleRole(role));
jbossSct.getUtil().setRoles(roleGroup);
return cachedAccount;
}
{code}
Instead of passing a {{null}}, passing the existing subject as set by the JASPIC callback
handler seems to work:
{code:java}
jbossSct.getUtil().createSubjectInfo(userPrincipal, ((AccountImpl)
cachedAccount).getCredential(), jbossSct.getUtil().getSubject());
{code}
When JASPIC's register session is used, Subject not propagated to
EJB
---------------------------------------------------------------------
Key: WFLY-6579
URL:
https://issues.jboss.org/browse/WFLY-6579
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.Final
Reporter: arjan tijms
Assignee: Darran Lofthouse
Labels: jaspic
When the JASPIC 1.1 register session ({{javax.servlet.http.registerSession}}) is used,
the authenticated identity (via the Subject) is not propagated to the EJB container.
The problems seems to be with {{JASPICAuthenticationMechanism.createAccount}}. When a
cached account is re-used, a {{null}} is passed for the {{Subject}} parameter in the call
to {{jbossSct.getUtil().createSubjectInfo}}. This will set indeed set a {{SubjectInfo}}
with subject being null.
{{EJBContext#getCallerPrincipal}} checks exactly this subject, and when seeing a null
will consider the user to be unauthenticated, even when the caller is authenticated in the
web layer.
See the code below:
{code:java}
// SAM handled the same principal found in the cached account: indicates we must use
the cached account.
if (cachedAccount != null && cachedAccount.getPrincipal() ==
userPrincipal) {
// populate the security context using the cached account data.
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
null); // PROBLEMATIC NULL
RoleGroup roleGroup = new
SimpleRoleGroup(SecurityConstants.ROLES_IDENTIFIER);
for (String role : cachedAccount.getRoles())
roleGroup.addRole(new SimpleRole(role));
jbossSct.getUtil().setRoles(roleGroup);
return cachedAccount;
}
{code}
Instead of passing a {{null}}, passing the existing subject as set by the JASPIC callback
handler seems to work:
{code:java}
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
jbossSct.getUtil().getSubject());
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)