multiple timeouts against the same IDP

[Flannery, Sean]

That explains it well.

Thank you.



On 2/27/14 12:28 PM, "Palle Girgensohn" <girgen at FreeBSD.org> wrote:

>27 feb 2014 kl. 18:09 skrev Flannery, Sean <sean.flannery at jwt.com>:
>
>> Hello,
>> 
>> I have the following problem and I'm not sure if it stems from a general
>> misunderstanding of SAML or if I'm just implementing things inccorectly
>>in
>> Shibboleth SP.
>> 
>> The issue:
>> 
>> * 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.
>> 
>> * 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 .  More
>> specifically, I have to give the ApplicationOverride a unique entityID
>> 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.
>> 
>> 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?
>> 
>> or
>> 
>> * 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?
>> 
>> Hope the question makes sense.  Thanks for your time.
>> 
>> Sean
>
>This is the way SAML works. Each application is its own SP. If you have a
>bunch of applications that have exactly the same demands, sure, you can
>put them together in one single SP, but if you have apps with different
>demands, you need should set up different SP:s for these apps.
>
>The IdP should't have any problems dealing with multiple SP:s, that is
>the basic idea of SAML. I don't believe they will refer to each SP as a
>"new realm", it is just another metadata entry in the federation.
>
>Palle
>