IdP3 Force Authentication Context for select CAS services

[O'Dowd, Josh]

> > p:defaultAuthenticationMethods="urn:duosecurity"
>
> That is NOT the value type for that property. If it works, ok, but I bet it breaks at some point.
>
> The value is a collection of AuthnContextClassRefPrincipal objects, much like with the descriptor beans themselves in the other file, so you should specify them as such, using a <list> element containing bean definitions. I realize that's uglier, but it is what's correct. I don't even know how Spring is managing to do that conversion, and depending on that is a bad idea.

I was the originator of this question, and as an example of what Scott is suggesting, I offer the following example RP override config:
		<bean id="DuoRelyingPartiesOverride" parent="RelyingPartyByName">
			<constructor-arg ref="umt.DuoOptInServices" />
		    <property name="profileConfigurations">
			<list>
			    <bean parent="CAS.LoginConfiguration">
				<property name="defaultAuthenticationMethods">
		    		    <list>
				        <bean parent="shibboleth.SAML2AuthnContextClassRef"
				            c:classRef="http://www.umt.edu/mfa" />
		                    	        <bean parent="shibboleth.SAML2AuthnContextClassRef"
		                       	           c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
		    		    </list>
		   		</property>
			    </bean>
			    <bean parent="SAML2.SSO">
		    		<property name="defaultAuthenticationMethods">
	    			    <list>
				        <bean parent="shibboleth.SAML2AuthnContextClassRef"
				    	    c:classRef="http://www.umt.edu/mfa" />
                        		    	        <bean parent="shibboleth.SAML2AuthnContextClassRef"
                   		    		    c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
	    			    </list>
				</property>
			    </bean>
			    <ref bean="SAML2.Logout" />
			</list>
		    </property>
		</bean>

Regards,

Josh O.


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, July 21, 2017 11:46 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: IdP3 Force Authentication Context for select CAS services

On 7/21/17, 12:00 PM, "users on behalf of Mak, David" <users-bounces at shibboleth.net on behalf of d.mak at northeastern.edu> wrote:

> Thank you Scott, for the quick reply. I went ahead and modified the 
> Unicon configuration file META-INF/shibboleth- idp/conf/global.xml to be as follows, replacing http://www.duosecurity.com/ with urn:duosecurity:

I wasn't suggesting the string was physically wrong. And urn:duosecurity is not a real URN. You can't just make them up.

Separately from your issue, I urge you to define a value for MFA that is technology neutral and is minted by you for your purposes, or see if you comply with InCommon's MFA profile and perhaps use that.

But the issue I was raising was the syntax, rather than the value. I was saying that I don't think you should be using this:

> p:defaultAuthenticationMethods="urn:duosecurity"

That is NOT the value type for that property. If it works, ok, but I bet it breaks at some point.

The value is a collection of AuthnContextClassRefPrincipal objects, much like with the descriptor beans themselves in the other file, so you should specify them as such, using a <list> element containing bean definitions. I realize that's uglier, but it is what's correct. I don't even know how Spring is managing to do that conversion, and depending on that is a bad idea.

> So, it shows the relying party group is being resolved properly. I 
> just don’t seem to get any action on the defaultAuthenticationMethods parameter.

I don't think that's physically possible based on the code, but all I can suggest is to file a bug. I don't anticipate it being reproducible, but anything's possible.

> Any suggestions to how I can debug this further would be appreciated.

The logs during authentication will show what it thinks the request specifies if anything. If it says that there are no special authentication requirements to evaluate, then there's no way it can be using that relying party config.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net