<div dir="ltr"><div><div><div>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 <a href="https://issues.shibboleth.net/jira/browse/IDP-784">https://issues.shibboleth.net/jira/browse/IDP-784</a>.   If possible, can you let me know if/when this is scheduled?   I've noticed <span class="im">CAS.ValidateConfiguration</span> doesn't support <span class="im"> a postAuthenticationFlows</span> flows attribute so I need to modify (or inherit the) <span class="im">CAS.ValidateConfiguration</span> 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.<br></div><br></div>Thanks,<br></div>cneberg<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 10:08 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 1/27/16, 10:58 AM, "users on behalf of cneberg" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:cneberg@gmail.com">cneberg@gmail.com</a>> wrote:<br>
<br>
<br>
<br>
>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.<br>
<br>
</span>I see.<br>
<span class=""><br>
>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.<br>
> 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.<br>
<br>
</span>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.<br>
<br>
Same would be true for activation conditions attached to a login flow since by definition the user identity just isn't known yet.<br>
<br>
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.<br>
<br>
So, yeah, might work, but it's situational.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>