multiple timeouts against the same IDP

[Cantor, Scott]

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