Forcing Duo by Service Provider

[Brandon McKean]

Thanks Scott, I've reverted that configuration back.

I've found this page in searching: 
https://wiki.shibboleth.net/confluence/display/IDP30/SAML2SSOConfiguration#SAML2SSOConfiguration-Authentication

And I've applied a configuration as follows:

> <bean parent="RelyingPartyByName" 
> c:relyingPartyIds="https://it-federation2.jmu.edu/shibboleth">
>                 <property name="profileConfigurations">
>                         <list>
>                                 <bean parent="SAML2.SSO" 
> p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT">
>                         <property name="defaultAuthenticationMethods">
>                                 <list>
>                                 <ref bean="MFASAML2Principal" />
>                                 </list>
>                         </property>
>                                 </bean>
>                         </list>
>                 </property>
>         </bean> 
Then I added this just under the initial bean stanza:

> <bean id="MFASAML2Principal" 
> parent="shibboleth.SAML2AuthnContextClassRef" 
> c:classRef="https://example.org/shibboleth/ac/classes/mfa" /> 

Unfortunately now I get this:

> 2017-03-29 13:43:51,136 - DEBUG 
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:370] - Profile 
> Action SelectAuthenticationFlow: Specific principals requested with 
> 'exact' operator: 
> [AuthnContextClassRefPrincipal{authnContextClassRef=https://example.org/shibboleth/ac/classes/mfa}] 
>
> 2017-03-29 13:43:51,137 - DEBUG 
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:386] - Profile 
> Action SelectAuthenticationFlow: No active results available, 
> selecting an inactive flow
> 2017-03-29 13:43:51,137 - DEBUG 
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:407] - Profile 
> Action SelectAuthenticationFlow: Checking for an inactive flow 
> compatible with operator 'exact' and principal 
> 'https://example.org/shibboleth/ac/classes/mfa'
> 2017-03-29 13:43:51,138 - DEBUG 
> [net.shibboleth.idp.authn.principal.PrincipalEvalPredicateFactoryRegistry:82] 
> - Registry located predicate factory of type 
> 'net.shibboleth.idp.authn.principal.impl.ExactPrincipalEvalPredicateFactory' 
> for principal type 'class 
> net.shibboleth.idp.saml.authn.principal.AuthnContextClassRefPrincipal' 
> and operator 'exact'
> 2017-03-29 13:43:51,139 - INFO 
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:428] - Profile 
> Action SelectAuthenticationFlow: None of the potential authentication 
> flows can satisfy the request
> 2017-03-29 13:43:51,167 - WARN 
> [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event 
> occurred while processing the request: RequestUnsupported
> 2017-03-29 13:43:51,179 - DEBUG 
> [org.opensaml.saml.common.profile.logic.DefaultLocalErrorPredicate:184] 
> - Error event RequestUnsupported will be handled with response
Am I missing something? Am I on the right track?

Thanks,

-- 
Brandon McKean
IT / Systems
Linux Administrator
(540)568-4235

On 03/29/2017 12:07 PM, Cantor, Scott wrote:
> On 3/29/17, 11:56 AM, "users on behalf of Brandon McKean" <users-bounces at shibboleth.net on behalf of mckeanbs at jmu.edu> wrote:
>
>> I'm trying to find a good way to force Duo use through the MFA flow
>> within the code stanza.
> That's not the right spot. You control it by setting the appropriate custom Principal inside the defaultAuthenticationMethods property on the relying party side, and in parallel requiring signed requests or blocking the RequestedAuthnContext "feature" for that SP, so that the imposed requirement can't be overridden. There are examples on that in the documentation.
>
>> Here's what I'm wanting to change:
> You don't want to change that, it's already correct for this case.
>
>> What I'm wanting to do is force it by entityID. I thought that'd be
>> something done in the relying-party but I can't find any options for that.
> See above.
>
> Look at the RelyingPartyConfiguration topic, scroll down to the profile-specific configuration part, and click on, probably, the SAML 2 SSO link. That has sections covering different options, one of which is Authentication related settings, and this is covered there with a full example that's safe.
>
> Of course, all of this is covering for a broken SP. The SP should be requesting this itself. (Not saying it's not necessary, but it's always important to understand this. When you talk about it, it's useful to emphasize to people that "hey, this application is broken" so they understand that you did work you shouldn't have had to do.)
>
> -- Scott
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170329/c6b6de88/attachment.html>