Authn cancel from a subflow.

[cneberg]

>I'm sure there are any number of small tree changes that would reliably
break the code.

I assume you mean any small changes to the context tree of the flow, as
done by my code would break the the code of the flow (which is my goal) -
so this is the path I should take if I need authorization in the IDP?

>It's just not a use case we have to do this. Authorization is the SPs job,
and having the IdP do it is viewed as a UI feature, not a security feature.

I agree with fine grained authorization there is no other way but to do
authorization in the SP, but for general corporate requirements doing it at
the IDP is simpler to enforce at scale, and just as important to audit at
scale.  I have already created a IDP hub so there is no other IDP's in play
- all SP's must trust a single IDP - so in my case there is a single point
where this could be implemented.    Maybe the level of autonomy given to
make security decisions is different in university environments where shib
is often used, than what is available to SP's in corporate environments.
In a company I think the autonomy is often much lower, and those additional
policies need to be implemented while still minimizing their
enforcement/audit point(s) and I think this is simple way to do it.

So I guess I'm asking is - could there be a blessed way for developers who
want to implement Authorization in the IDP to do it securely?    Either the
way you describe above - becomes the blessed way, OR some new API we could
code to?   I could open a case if this is something you are willing to
discuss more.

Thanks,
Topher

On Thu, Aug 6, 2015 at 10:23 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 8/5/15, 8:48 PM, "users on behalf of cneberg" <
> users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
>
> >I'm working on a plugin which could handle problematically allowing or
> forbidding access to a specific entityID based on properties of the
> authentication - such as the authentication type, and/or properties of the
> user such as what groups they are in.
> >I was building this based on modeling it after the attribute release
> flow, but now that sounds wrong.   Where would I put code which does this
> and can cancel the flow securely?
>
> I'm not prepared to claim there is any way to do it with an absolute
> degree of certainty once the login is done. I would have to look at the
> code and determine exactly which context tree manipulations would do the
> trick. Even destroying user information might still just result in an empty
> assertion.
>
> Probably the one absolute that would do it in the SAML case is destroying
> the outbound message context because that's where the information on
> encoding the response lives. I'm sure there are any number of small tree
> changes that would reliably break the code.
>
> It's just not a use case we have to do this. Authorization is the SPs job,
> and having the IdP do it is viewed as a UI feature, not a security feature.
>
> -- 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/20150806/4020d3e8/attachment.html>