minimizing system directory changes

[cneberg]

In a university use case, or any use case where ownership of the data is
different then the identity provider I see your point - but I think I'm
representing a new corporate use case where the identity provider does also
own the data - many cots in house products now come with SAML support. I've
seen shibboleth 3 or maybe it was incommon email last year about what
should the future of the shibboleth 3 identity platform be - and I guess
one enhancement request at a time I'm bringing ideas into the mix.  I'm not
sure that's the best path but I'm not sure of what the alternative path's
are.

Thanks,
Christopher

On Wed, Jan 27, 2016 at 12:37 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 1/27/16, 1:12 PM, "users on behalf of cneberg" <
> users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
> >
> >Interesting I assumed it would be a popular.   Having a central way to
> control even loose authorization is powerful.
>
> I think it's misguided. One of the differences here is that Shibboleth was
> designed around a world in which the resources being protected were not
> owned by the IdP's organization, and enterprises using federation really
> care much more about the case where they are. If you own the resources, you
> certainly can't expect me to enforce the access control for you (vs. me
> providing the data to help determine the decision).
>
> My experience is that creating rules at the IdP is inflexible and leads to
> unanticipated consequences when people figure out how to exploit the weird
> policies people try and make the IdP apply. A common example of that is
> when managers try and force us to deploy "simple" rules based on user
> affiliation or role, and are totally incapable of understanding that roles
> overlap routinely.
>
> -- 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/20160127/e4672ac5/attachment-0001.html>