<div dir="ltr"><div><div><div>
>It dropped off my radar, I scheduled it so it at least is considered. 
There is no schedule for 3.3 right now, and I doubt it would be very 
soon.<br><br>Thank you for considering it.<br><br>>thought that flow was back channel ticket checking. Having a post-login 
intercept doesn't work for a non-authentication profile because those 
intercepts are expected to permit views.<br><br></div>You are correct, and after changing the intercept to CAS.LoginConfiguration my authz custom class does work.   Thank you!<br><br>>>injected Predicate that just defaults to "true" and would be overridable
 though, just to make it easier. But this is not a common feature, and 
adding more chrome that 99% of deployers have to overlook isn't a 
direction I like.<br><br></div>Interesting I assumed it would be a popular.   Having a central way to control even loose authorization is powerful.  I know Ping has support for something similar.<br><br></div>-Topher<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 11:21 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, 11: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 second half of my customization would be made easier by issue<br>
</span>><a href="https://issues.shibboleth.net/jira/browse/IDP-784" rel="noreferrer" target="_blank">https://issues.shibboleth.net/jira/browse/IDP-784</a> If possible, can you let me know if/when this is scheduled?<br>
<br>
It dropped off my radar, I scheduled it so it at least is considered. There is no schedule for 3.3 right now, and I doubt it would be very soon.<br>
<br>
Using an outbound intercept is probably the best way right now since that runs during the final encoding of the message and if that fails it's clearly not issuing anything.<br>
<span class=""><br>
>I've noticed CAS.ValidateConfiguration doesn't support<br>
>a postAuthenticationFlows flows attribute so I need to modify (or inherit the)<br>
>CAS.ValidateConfiguration class to give it an entry point to call my custom code.<br>
<br>
</span>I thought that flow was back channel ticket checking. Having a post-login intercept doesn't work for a non-authentication profile because those intercepts are expected to permit views.<br>
<br>
All profiles should run the inbound and outbound intercepts though, and I think Marvin is cleaning that up for the CAS flows. It's just a useful extension point.<br>
<span class=""><br>
>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>
<br>
</span>Everything is per-profile in the IdP, there is nothing at the level you mean. Meaning no matter what, it would have to get turned on per-profile unless it were just baked in as a default. It's possible something like that could be done via an injected Predicate that just defaults to "true" and would be overridable though, just to make it easier. But this is not a common feature, and adding more chrome that 99% of deployers have to overlook isn't a direction I like.<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>