minimizing system directory changes

[cneberg]

 >>Not new at all, but it tends to lead to a sloppy separation of concerns
that doesn't work well at scale.

Sorry for the confusion, I didn't mean authorization at the IDP was new.
I meant my corporate use case of authorization - ie its not at scale and
didn't have data ownership issues. So perhaps it didn't fit in the
philosophical objections given previously.

>>Also, the main goal of the new platform was radical extensibility, i.e.
making things we didn't agree with much easier to build with small amounts
of code so that we weren't the gating factor.

Ok, I've read documents referring to that too but I was referring to
discussions of oauth and OpenID Connect and other future technologies, and
I assumed the discussion of shib 3 going forward was beyond extensibility
and included new use cases and directions for the project.

>> In this case, your goal of authorization is really secondary to the
question of what hooks exist or might be missing.

Fair enough.  Thank you.

>>I don't know that, upon studying it, I'll conclude that the right place
for this isn't there already with the outbound intercept hook. The only
reason I was initially not thinking that way is efficiency, since that runs
rather late and we can probably do something a little less late in the
sequence.

That might be ok.   Thank you for looking into it.

-Christopher

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

> On 1/27/16, 2:18 PM, "users on behalf of cneberg" <
> users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
>
> >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
>
> Not new at all, but it tends to lead to a sloppy separation of concerns
> that doesn't work well at scale.
>
> >- 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.
>
> Having the IdP do authorization is not a new idea, but it was always
> something approached with a large grain of salt.
>
> Also, the main goal of the new platform was radical extensibility, i.e.
> making things we didn't agree with much easier to build with small amounts
> of code so that we weren't the gating factor. In this case, your goal of
> authorization is really secondary to the question of what hooks exist or
> might be missing.
>
> I don't know that, upon studying it, I'll conclude that the right place
> for this isn't there already with the outbound intercept hook. The only
> reason I was initially not thinking that way is efficiency, since that runs
> rather late and we can probably do something a little less late in the
> sequence.
>
> -- 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/36dc53fa/attachment.html>