multiple timeouts against the same IDP

[Palle Girgensohn]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://shibboleth.net/pipermail/users/attachments/20140227/12ff14ac/attachment.bin