<div dir="ltr"><div>Thank you that worked well.<br><br>><span class="im"></span>You don't need an abstract parent bean at all, but it certainly 
doesn't need to be in there, any bean file in the root context will 
work. You shouldn't usually need your own descriptor type at all, 
really, but that depends on what you're doing I guess.<br><br></div><div>Can you suggest a simpler design?   I'm a Spring newbie.  Also, as a new wrinkle I'm testing CAS auth, and I'm not having luck just simply putting  <ref bean="CAS.ValidateConfiguration"  p:postAuthenticationFlows="authng-authz" (error messages are below).    I'm looking for a simple and general design as possible.   My primary use case for authz is ensuring dynamic level of assurance (authentication level) requirements are enforced the same on the front end authentication as the backend without having to modify the SP's themselves.   Is that something you'd generally support if I filed an enhancement request?<br><br>The error I'm seeing when I enable the postAuthenticationFlow.<br><br>2016-01-25 09:46:21,683 - DEBUG [net.shibboleth.idp.cas.service.PatternServiceRegistry:85] - 111.111.11.1 - Evaluating whether <a href="https://test.mysite.com/cgi-bin/test">https://test.mysite.com/cgi-bin/test</a> matches http://([A-Za-z0-9_-]+\.)*mysite\.com(:\d+)?/.*<br>2016-01-25 09:46:21,684 - DEBUG [net.shibboleth.idp.cas.flow.impl.BuildRelyingPartyContextAction:84] - 111.111.11.1 - Setting up RP context for unverified relying party <a href="https://test.mysite.com/cgi-bin/test">https://test.mysite.com/cgi-bin/test</a><br>2016-01-25 09:46:21,696 - ERROR [net.shibboleth.idp.relyingparty.impl.ReloadingRelyingPartyConfigurationResolver:107] - 111.111.11.1 - RelyingPartyResolver 'shibboleth.RelyingPartyConfigurationResolver': error looking up Relying Party: Invalid configuration.<br>2016-01-25 09:46:21,697 - DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:131] - 111.111.11.1 - Profile Action SelectRelyingPartyConfiguration: No relying party configuration applies to this request<br>2016-01-25 09:46:21,706 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - 111.111.11.1 - An error event occurred while processing the request: InvalidRelyingPartyConfiguration<br></div><div><br></div>-Christopher<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 6:13 PM, 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/13/16, 6:52 PM, "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>
>I've written my own per-SP authz plugin which runs using attribute consent as a model.  I've attempted to minimize changes to the system directories but these changes remain. Do you have ideas where I can move one or more of the changes - so they are not<br>
> overwritten during an upgrade?<br>
><br>
>*defines the name intercept/authng-authz and location of authng-authz flow<br>
><br>
>file: system/conf/webflow-config.xml<br>
><br>
> <webflow:flow-location id="intercept/authng-authz" path="../conf/authng/authng-authz-flow.xml" /><br>
<br>
</span>User flows are loaded using a naming convention and do not need to be installed with a name. It's discussed in the documentation in various places, authentication for sure, but I thought a few other places. Put it in flows/intercept/authng-authz/authng-authz-flow.xml and it should load with the name intercept/authng-authz<br>
<span class=""><br>
>* Creates a new bean for authorization checking<br>
><br>
>file: system/conf/profile-intercept-system.xml<br>
><br>
><br>
>  <bean id="shibboleth.authng.AuthzFlow" abstract="true"<br>
>          class="com.somesite.auth.actions.AuthzFlowDescriptor" /><br>
<br>
</span>You don't need an abstract parent bean at all, but it certainly doesn't need to be in there, any bean file in the root context will work. You shouldn't usually need your own descriptor type at all, really, but that depends on what you're doing I guess.<br>
<span class=""><br>
>*Creates a new endstate for authorization failures.<br>
><br>
>file: system/flows/intercept/intercept-abstract-flow.xml<br>
><br>
> <end-state id="AuthzRejected" /><br>
<br>
</span>That goes in conf/intercept/intercept-events-flow.xml<br>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br></div>