minimizing system directory changes

[cneberg]

True I run my class twice.  Once at the beginning to select auth level, and
once after auth -  to do enforcement.   When it runs after auth - it has
access to user attributes as well so it can deny the access based on group
membership or other attributes.   The second half of my customization would
be made easier by issue https://issues.shibboleth.net/jira/browse/IDP-784.
If possible, can you let me know if/when this is scheduled?   I've noticed
CAS.ValidateConfiguration doesn't support a postAuthenticationFlows flows
attribute so I need to modify (or inherit the) CAS.ValidateConfiguration
class to give it an entry point to call my custom code.    If you are
scheduling adding the custom gateting step at a high enough level it might
cover all protocols.   It's a security configuration issue that I have to
remember to enable the enforcement class with each new protocol I enable.
It would be better if I could just enable it once at a high enough level it
covered all protocols.

Thanks,
cneberg

On Wed, Jan 27, 2016 at 10:08 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 1/27/16, 10:58 AM, "users on behalf of cneberg" <
> users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
>
> >The main thing my class is doing so far is enforcing a particular minimum
> authentication level based on the IP address of the client.  External
> clients have higher authentication requirements than internal ones to the
> same SP.
>
> I see.
>
> >But in the future I might do external DB lookups based on various
> attributes of the User and SP to make a determination as well.   So I guess
> my question is do you support a dynamic determination of authentication
> level for the REquestedAuthnContext level based on user defined class.
> > Looking at the docs, it looks like an activation condition which selects
> a relying party config which enforces the correct auth requirements might
> be a start.
>
> Only if it needs access solely to information available at the beginning.
> That wouldn't include user identity, attributes, etc. It would include
> client address.
>
> Same would be true for activation conditions attached to a login flow
> since by definition the user identity just isn't known yet.
>
> The mild exception to that is if you force initial-authn via password,
> unconditionally, and then put conditions on the "main" login flows that
> depend on information acquired after the password step.
>
> So, yeah, might work, but it's situational.
>
> -- 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/39eac6bf/attachment.html>