MFA Resources
Jeremiah Garmatter
j-garmatter at onu.edu
Tue Jul 28 00:49:32 UTC 2020
I appreciate the help but the more I hear about all of this SAML and
SpringWebFlows, the more I think I'm messing this up or missing some
important information.
I kept receiving errors that stated my relying-party.xml was misconfigured
but they provided little more info than that. Something about SAML binds. I
was getting mixed up with my changes so I decided to restart from my
backup. At the moment, I have a duo.properties with the correct keys and
api-host (verified through CAS). I have a general-authn.xml with default
entries for duo and mfa (1 below), a default mfa-authn-config.xml, the
relying-party.xml has a default profile configuration (2 below) with what
seems like overrides for every service related to emailAddress.
Points of confusion:
"define something to represent this mechanism to the outside "SAML" world
as an authentication context class by adjusting the supportedPrincipals
property on the Duo (and probably MFA) flow descriptors in
*conf/authn/general-authn.xml*." from
https://wiki.shibboleth.net/confluence/display/IDP4/DuoAuthnConfiguration.
I thought I could use Stanford Universities MFA context (
https://uit.stanford.edu/service/saml/profile/mfa/forced) as it seemed like
it would be a good fit, however they mentioned those profiles were for SPs
so I wasn't sure if I could even implement them. I attempted anyway with
the following bean within the supportedPrincipals of the default authn/Duo
mechanism: <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="
https://saml.stanford.edu/profile/mfa/forced" />. I'm not sure if this will
even work, I will reiterate that I have little experience with Java and xml
and no experience with the Spring WebFlow.
Should I be configuring some sort of script within the mfa-authn-config.xml
script? Prior to this upgrade we were running shibboleth 3.1.2, which
didn't even support multifactor from what I understand, so I'm not sure how
mfa factors in to this whole situation. We only needed username and
password authentication at that time. This single-factor authentication
still works after the upgrade to shibboleth 4.0. Am I supposed to configure
MFA to override the single factor username to allow for multiple forms of
authentication? I have no Idea how this works and while reading the
shibboleth documentation I find myself more confused than when I started.
How does the ProfileConfiguration-Authentication link provided in the last
email fit in with the relying-party.xml configuration I have in (2)? If I
try to define the default auth method for a specific service provider, I
was able to sign in to the service with only my username and password (no
Duo enrollment or prompt) or I was met with another generic
"relying-party.xml misconfiguration" error.
All I want is to sign in to one particular service provider with username
and password, then be prompted to authenticate through Duo, and be brought
back to my service if all goes well. I apologize for being so brash, but I
don't have the time to become a spring developer and those who set this
system up have left my place of business, taking their experience with them.
As usual, help is appreciated, but if what I ask is beyond the scope of
this email list please refer me to another group.
(1.)general-authn.xml:
<bean id="authn/Duo" parent="shibboleth.AuthenticationFlow"
p:forcedAuthenticationSupported="true"
p:nonBrowserSupported="false">
<!--
The list below should be changed to reflect whatever locally- or
community-defined values are appropriate to represent MFA. It is
strongly advised that the value not be specific to Duo or any
particular technology.
-->
<property name="supportedPrincipals">
<list>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="http://example.org/ac/classes/mfa" />
<bean parent="shibboleth.SAML1AuthenticationMethod"
c:method="http://example.org/ac/classes/mfa" />
</list>
</property>
</bean>
<bean id="authn/MFA" parent="shibboleth.AuthenticationFlow"
p:passiveAuthenticationSupported="true"
p:forcedAuthenticationSupported="true">
<!--
The list below almost certainly requires changes, and should
generally be the
union of any of the separate factors you combine in your
particular MFA flow
rules. The example corresponds to the example in
mfa-authn-config.xml that
combines IPAddress with Password.
-->
<property name="supportedPrincipals">
<list>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol" />
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
/>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Password" />
<bean parent="shibboleth.SAML1AuthenticationMethod"
c:method="urn:oasis:names:tc:SAML:1.0:am:password"
/>
</list>
</property>
</bean>
(2.) relying-party.xml:
<!--
Default configuration, with default settings applied for all profiles,
and enables
the attribute-release consent flow.
-->
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<property name="profileConfigurations">
<list>
<bean parent="Shibboleth.SSO" />
<ref bean="SAML1.AttributeQuery" />
<ref bean="SAML1.ArtifactResolution" />
<bean parent="SAML2.SSO" />
<ref bean="SAML2.ECP" />
<ref bean="SAML2.Logout" />
<ref bean="SAML2.AttributeQuery" />
<ref bean="SAML2.ArtifactResolution" />
</list>
</property>
</bean>
<bean parent="RelyingPartyByName" c:relyingPartyIds="SP's
Entity-ID">
<property name="profileConfigurations">
<list>
<bean parent="Shibboleth.SSO"
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
/>
<bean parent="SAML2.SSO"
p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
/>
</list>
</property>
</bean>
-Jeremiah Garmatter, Systems Administrator
-Ohio Northern University, Class of 2020
-j-garmatter at onu.edu
On Mon, Jul 27, 2020 at 4:09 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 7/27/20, 3:43 PM, "users on behalf of Jeremiah Garmatter" <
> users-bounces at shibboleth.net on behalf of j-garmatter at onu.edu> wrote:
>
> >I'm still confused about the services though. I looked into the
> relying-parties.xml and found that my predecessors
> > included some profile configurations for most of the services. An
> example of one is included:
>
> The SAML2.SSO bean has a lot of other settings. One of them is
> defaultAuthenticationMethods. All the profiles that involve a user logging
> in have that property.
>
>
> https://wiki.shibboleth.net/confluence/display/IDP4/ProfileConfiguration-Authentication
>
> Second example is what you're asking about.
>
> > Would I simply have to create a new bean with the
> parent=shibboleth.SAML2AuthnContextClassRef passing in a class
> > reference to my mfa method within the profileConfigurations property?
>
> Sort of, but the example includes the right syntax (or one syntax among a
> dozen that are equivalent in Spring).
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> 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/20200727/4a7b9373/attachment.htm>
More information about the users
mailing list