[
https://issues.apache.org/jira/browse/CXF-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159297#comment-13159297
]
Colm O hEigeartaigh commented on CXF-3940:
------------------------------------------
> 2) The check wether or not it is a SAML Token is based on
> "receivedToken.isDOMElement()". This is confusing, since a
> UsernamePasswordToken would also be a valid DOMElemenet...
Nope, UsernameTokens and BinarySecurityTokens are parsed into JAXB objects by
the STS, but SAML Assertions are not.
Colm.
> A SAML Token requested OnBehalfOf should hide the actual requestor and should
> only contain the OnBehalfOf Identity
> ------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-3940
> URL: https://issues.apache.org/jira/browse/CXF-3940
> Project: CXF
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 2.5
> Reporter: Jan Bernhardt
> Labels: SAML, WS-Trust, sts
> Fix For: 2.5.1
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> As far as I know, to request an OnBehalfOf Token should not simply result in
> adding a related SAML Attribute (as it would be ok for ActAs). OnBehalfOf
> should deliver a Token where "only" the OnBehalfOf Principal is contained.
> Therefor the SAML Subject should match the requested OnBehalfOf Principal and
> not the Principal which was authenticated based on the security token sent in
> the WS-Security header...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
