Sharing SP Metadata amongst multiple SPs
Phil Lello
phil at dunlop-lello.uk
Sat Nov 7 14:29:08 EST 2015
Thanks Scott, very helpful as always.
If my questions seem rather inconsistent, it's probably because I'm coming
from several perspectives, as I'm a contractor that works with multiple
clients, as well having ambitions to develop my own services primarily
targeted at universities.
SAML/Shibboleth isn't really a core skill for me at the moment, but I'm
finding it increasingly useful to develop a full appreciation for federated
identity management, as when it's done right, everybody wins.
Phil
On Sat, Nov 7, 2015 at 7:14 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 11/7/15, 2:08 PM, "users on behalf of Phil Lello" <
> users-bounces at shibboleth.net on behalf of phil at dunlop-lello.uk> wrote:
>
>
> >
> >Soapbox is fine with me; there were two scenarios I had in mind, rapid
> deployment of production environments (where I'll agree it's at best
> sub-optimal), and development environments where it's desirable to spin up
> n-m instances that should be identical from an integration perspective.
>
> Dev's a bit of a different matter. I generally register (server)
> development systems under the same entityID and key as production, just
> adding the endpoints. If they have dev and QA I'll usually suggest that
> merge QA and prod, but leave dev separate.
>
> > Whilst I agree the avoided work isn't much in principal, my experience
> is that application development teams are generally separate from the
> shibboleth team (who are generally under-resourced), which inevitably leads
> to long delays.
>
> When you're talking about "inside the firewall" and use in an enterprise
> situation, most of what I was talking about goes out the window. Then it's
> more a matter of local norms and workflow. And if you control the IdP, that
> goes hand in hand, since you can choose to disable endpoint checking for
> those SPs.
>
> That's why I was saying it matters a lot exactly how much control you have.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151107/df08b6cc/attachment.html>
More information about the users
mailing list