multiple timeouts against the same IDP

[Flannery, Sean]

Thanks, Scott.

I didn't realize you didn't have to give the application override a unique
entityID, so that solved my problem.  I now just have

<ApplicationOverride id="strictTimeout">
   <Sessions lifetime="1800" timeout="1800" maxTimeSinceAuthn="1800"
relayState="ss:mem"
        checkAddress="false" handlerSSL="false" cookieProps="http"
handlerURL="/strictTimeout/Shibboleth.sso">
    </Sessions>
        </ApplicationOverride>

And it works.  Thank you for your time.

Should it matter, on 'realm', that's the term the IDP team uses when they
give me a new metadata entry.  They use a vendor tool and perhaps that
nomenclature comes from the vendor's tool.  Not sure.  Sorry for the
confusion on that.


Appreciate the help.

Sean




On 2/27/14 12:56 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

>On 2/27/14, 12:09 PM, "Flannery, Sean" <sean.flannery at jwt.com> wrote:
>>
>>* we have a request to protect some apps with much stricter session
>>timeouts than other apps (at the SP level), but our IDP team wants these
>>different apps to use the same realm.
>
>There is no such thing as "realm" in SAML, so you're going to need to
>explain what that means.
>
>>* I've used the ApplicationOverride feature to protect different URLs
>>with
>>different timeouts and that works fine, but, at least the way I'm doing
>>it, a new ApplicationOverride entry requires a unique IDP realm .
>
>No, it doesn't.
>
>>More specifically, I have to give the ApplicationOverride a unique
>>entityID
>
>That is not a requirement, no. But now you're talking about the SP's name,
>and up above you're saying something about "IdP realm", which sounds like
>an IdP name.
>
>>and, by doing so, that means it won't match the audienceRestriction
>>coming
>>back from the default IDP realm, thus the IDP team must raise a new realm
>>for each override.
>
>When the SP makes a request, it will identify itself. So there's no way
>the audience won't match unless you're doing something odd.
>
>>What I'm wondering is:
>>
>>* is that just the way SAML is supposed to work, and you're not supposed
>>to have different SP apps with different timeouts, pointing to the same
>>IDP realm?
>
>Again, I don't know what IdP realm means. But SAML has no concept of a
>session timeout, so none of this has anything to do with SAML, it's
>implementation specific. Timeouts in this implementation are based on
>policy set at the application level, which is not a SAML concept.
>
>>* is there a  better way to implement this?  Where I can setup different
>>app policies in the SP, but still be in compliance with the
>>audienceRestriction that comes back from the IDP?
>
>All overrides can be logically one SAML SP. I have to presume the problem
>here is self-inflicted and that you're creating extra work for yourself by
>making them multiple entities.
>
>-- Scott
>
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net