minimizing system directory changes

[cneberg]

 >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.

Thank you for considering it.

>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.

You are correct, and after changing the intercept to CAS.LoginConfiguration
my authz custom class does work.   Thank you!

>>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.

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.

-Topher

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

> On 1/27/16, 11:58 AM, "users on behalf of cneberg" <
> users-bounces at shibboleth.net on behalf of cneberg at gmail.com> wrote:
>
>
>
> >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?
>
> 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.
>
> 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.
>
> >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.
>
> 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.
>
> 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.
>
> >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.
>
> 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.
>
> -- 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/971dd455/attachment.html>