CXF-Fediz
  1. CXF-Fediz
  2. FEDIZ-48

Support wfresh properly in the IdP

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.2
    • Fix Version/s: 1.1.0, 1.0.3
    • Component/s: None
    • Labels:
      None

      Description

      This task is to properly support wfresh in the IdP. Currently, we only support "wfresh" in the context of forcing a re-authentication if it's equal to "0". We should also use it to specify the Lifetime when requesting a token from the STS.

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        1d 3h 41m 1 Colm O hEigeartaigh 23/Jan/13 14:44
        Resolved Resolved Reopened Reopened
        1d 20h 5m 1 Colm O hEigeartaigh 25/Jan/13 10:49
        Reopened Reopened Resolved Resolved
        10d 23h 30m 1 Colm O hEigeartaigh 05/Feb/13 10:20
        Resolved Resolved Closed Closed
        17d 6h 59m 1 Colm O hEigeartaigh 22/Feb/13 17:19
        Colm O hEigeartaigh made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Colm O hEigeartaigh made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Colm O hEigeartaigh added a comment -

        Hi Oli,

        Could you review the latest commit I made?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Oli, Could you review the latest commit I made? Colm.
        Hide
        Oliver Wulff added a comment -

        As per my understanding, there is no relation between wfresh and the lifetime element in the RST. The wfresh parameter can only ensure that the original authentication is not too long ago. If it is 5 then it means that the IDP token must not have been issued longer ago than 5 minutes. If it's 0, the browser user must re-authenticate himself. The wfresh value must be checked against the Created element in the cached IDP token. You should still be able to configure how long an IDP token is valid by default.

        I proposed in dev mailing list, that some application specific configuration is required. You should be able to configure the lifetime as well per application but this is for the RP token whereas wfresh relates to the IDP (authentication) token.

        WDYT?

        Show
        Oliver Wulff added a comment - As per my understanding, there is no relation between wfresh and the lifetime element in the RST. The wfresh parameter can only ensure that the original authentication is not too long ago. If it is 5 then it means that the IDP token must not have been issued longer ago than 5 minutes. If it's 0, the browser user must re-authenticate himself. The wfresh value must be checked against the Created element in the cached IDP token. You should still be able to configure how long an IDP token is valid by default. I proposed in dev mailing list, that some application specific configuration is required. You should be able to configure the lifetime as well per application but this is for the RP token whereas wfresh relates to the IDP (authentication) token. WDYT?
        Hide
        Colm O hEigeartaigh added a comment -

        Hi Oli,

        I'm a bit confused by the definition in the spec:

        > An IP/STS SHOULD NOT issue a token with a longer lifetime. If specified as “0” it indicates a request for > the IP/STS to re-prompt the user for authentication before issuing the token.

        So if the RP passes "wfresh=0", what should the subsequent Expiry date of the STS issued token be? According to the above it should not be longer than the given value of wfresh.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Oli, I'm a bit confused by the definition in the spec: > An IP/STS SHOULD NOT issue a token with a longer lifetime. If specified as “0” it indicates a request for > the IP/STS to re-prompt the user for authentication before issuing the token. So if the RP passes "wfresh=0", what should the subsequent Expiry date of the STS issued token be? According to the above it should not be longer than the given value of wfresh. Colm.
        Colm O hEigeartaigh made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Oliver Wulff added a comment -

        Doesn't wfresh mean how much time ago the authentication can have occured? If it's 5, that the authencation must not have occured longer than 5 minutes ago. But we need some sort of mechanism to specify per application how long its token can be valid (besides the usage of the wreq parameter which is the RST for the STS)
        http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175013

        Show
        Oliver Wulff added a comment - Doesn't wfresh mean how much time ago the authentication can have occured? If it's 5, that the authencation must not have occured longer than 5 minutes ago. But we need some sort of mechanism to specify per application how long its token can be valid (besides the usage of the wreq parameter which is the RST for the STS) http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175013
        Colm O hEigeartaigh made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Colm O hEigeartaigh created issue -

          People

          • Assignee:
            Colm O hEigeartaigh
            Reporter:
            Colm O hEigeartaigh
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development