cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FEDIZ-140) IDP caches outdated SAML Tokens
Date Tue, 12 Jan 2016 15:50:39 GMT

    [ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094110#comment-15094110
] 

Colm O hEigeartaigh edited comment on FEDIZ-140 at 1/12/16 3:50 PM:
--------------------------------------------------------------------

Hi Jan,

I took a look at this issue. The problem was actually with the SAML SSO parsing code in CXF.
It was taking the Session NotOnOrAfter value as the expiry of the received token, and not
falling back to the SubjectConfirmationData NotOnOrAfter if the former was null. Therefore
no expiry was associated with the token received in the IdP. The error was when the STS is
validating the token.

I've fixed this now + I tested that it is working correctly. The IdP will redirect back to
the SAML SSO IdP if the cached token is no longer valid. This is the same behaviour as that
of the WS-Federation protocol in the IdP.

I've added a boolean "tokenExpirationValidation" to the WfreshParser in the IdP to disable
the expiry check per-request. It defaults to "true" to preserve past behaviour (note that
same configuration option in the plugins defaults to "false"). Edit: Just to note that the
STS may reject the expired token - this is up to the STS implementation.

Colm.


was (Author: coheigea):
Hi Jan,

I took a look at this issue. The problem was actually with the SAML SSO parsing code in CXF.
It was taking the Session NotOnOrAfter value as the expiry of the received token, and not
falling back to the SubjectConfirmationData NotOnOrAfter if the former was null. Therefore
no expiry was associated with the token received in the IdP. The error was when the STS is
validating the token.

I've fixed this now + I tested that it is working correctly. The IdP will redirect back to
the SAML SSO IdP if the cached token is no longer valid. This is the same behaviour as that
of the WS-Federation protocol in the IdP.

I've added a boolean "tokenExpirationValidation" to the WfreshParser in the IdP to disable
the expiry check per-request. It defaults to "true" to preserve past behaviour (note that
same configuration option in the plugins defaults to "false").

Colm.

> IDP caches outdated SAML Tokens
> -------------------------------
>
>                 Key: FEDIZ-140
>                 URL: https://issues.apache.org/jira/browse/FEDIZ-140
>             Project: CXF-Fediz
>          Issue Type: Bug
>          Components: IDP
>    Affects Versions: 1.2.1
>            Reporter: Jan Bernhardt
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.3.0, 1.2.2
>
>
> I did some tests today with a SAML SSO trusted IDP. During these tests I've noticed that
the Fediz-IDP will only redirect me once to the trusted 3rd party IDP for login. Then it caches
my (3rd party) SAML token even if the token is not valid because the lifetime of that token
ended. The result is, that I see an error page at the IDP, instead of getting redirected back
again to my 3rd party IDP.
> I see two solutions for this issue.
> Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of cached tokens.
> Option 2: Redirect back to 3rd Party IDP if cached token is not valid any longer.
> I think it would be good if both options could be provided within Fediz, leaving the
choice to the user, depending on their use case.
> A current workaround is to disable token caching in the IDP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message