[
https://issues.apache.org/jira/browse/FEDIZ-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16684034#comment-16684034
]
Pedro Alves edited comment on FEDIZ-232 at 11/12/18 4:27 PM:
-------------------------------------------------------------
Thank you for your reply, [~coheigea]
Additionally, we are also struggling with a couple more issues related with the
RequestState validation with SAML SSO protocol.
1 - In
org.apache.cxf.fediz.core.samlsso.SAMLSSOResponseValidator#validateAudienceRestrictionCondition
the spIdentifier is expected to match one of the entries in
audienceRestrictions. But this spIdentifier is in fact set to the realm in
org.apache.cxf.fediz.core.processor.SAMLProcessorImpl#createSignInRequest (line
428), which I suspect to be a bug. Let me know if I'm missing something.
2 - In
org.apache.cxf.fediz.core.samlsso.SAMLSSOResponseValidator#validateSubjectConfirmation,
subjectConfData.inResponseTo is expected to match the saved requestId. We are
using cxf-sts and we see no clear way of sending the requestId with the token
request. One possible way would be to pass in the requestId as customContent in
the token request
(org.apache.cxf.ws.security.trust.AbstractSTSClient#customContent). Would you
recommend a better way of doing it?
Thanks
was (Author: pedroalves):
Thank you for your reply, [~coheigea]
Additionally, we are also struggling with a couple more issues related with the
RequestState validation.
1 - In
org.apache.cxf.fediz.core.samlsso.SAMLSSOResponseValidator#validateAudienceRestrictionCondition
the spIdentifier is expected to match one of the entries in
audienceRestrictions. But this spIdentifier is in fact set to the realm in
org.apache.cxf.fediz.core.processor.SAMLProcessorImpl#createSignInRequest (line
428), which I suspect to be a bug. Let me know if I'm missing something.
2 - In
org.apache.cxf.fediz.core.samlsso.SAMLSSOResponseValidator#validateSubjectConfirmation,
subjectConfData.inResponseTo is expected to match the saved requestId. We are
using cxf-sts and we see no clear way of sending the requestId with the token
request. One possible way would be to pass in the requestId as customContent in
the token request
(org.apache.cxf.ws.security.trust.AbstractSTSClient#customContent). Would you
recommend a better way of doing it?
Thanks
> 'wctx' parameter mandatory but protocol does not require
> --------------------------------------------------------
>
> Key: FEDIZ-232
> URL: https://issues.apache.org/jira/browse/FEDIZ-232
> Project: CXF-Fediz
> Issue Type: Bug
> Reporter: Christian Fischer
> Priority: Major
>
> For logins which are not initiated by a valid session on the RP side the user
> cannot be authenticated because the wctx parameter is missing or has the
> wrong value.
> There are at least two scenarios in which this causes a unwanted behaviour of
> the system.
> * First is if the IDP/login page is bookmarked and returns only later after
> the session on the RP is timed out.
> * Second is something similar to a IDP initiated login flow. It's not in the
> WS federation protocol specification but according to our tests fediz could
> easily allow that if the 'wctx' check is removed.
> In the protocol specification the 'wctx' parameter is also only optional,
> where fediz expects it to be always present. There is a comment with respect
> to CSRF prevention but our security team didn't see the case for this since
> there is no passive way of authentication is used. In fact it's the actual
> authentication request that is supposed to be protected, but we don't see the
> need.
>
> One option (if the CSRF case is valid) would be to at least disable the
> 'wctx' state validation by setting a flag.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
