InvalidNameIDPolicy occurs when using multi-factor authentication
Noriyuki TAKEI
ntakei at sios.com
Sun Feb 3 11:30:31 EST 2019
Thanks for your reply.
> Happened? You’ll need a log of the attribute resolution. My guess would
be that the principal is different in the two cases and when you present
that to LDAP it doesn’t resolve...
What does "the principal is different in the two cases" means?
I found out that the other attributes except "ImmutableID" can be resolved
from idp-process.log as below.
2019-02-04 00:34:06,103 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractDataConnector:143] - Data
Connector 'myLDAP': Attribute 'mail': Values '[StringAttributeValue{value=
XXX at example.com}]'
2019-02-04 00:34:06,104 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractDataConnector:143] - Data
Connector 'myLDAP': Attribute 'displayName': Values
'[StringAttributeValue{value=XXX XXX}]'
2019-02-04 00:34:06,105 - DEBUG
[net.shibboleth.idp.attribute.resolver.AbstractDataConnector:143] - Data
Connector 'myLDAP': Attribute 'givenName': Values
'[StringAttributeValue{value=XXX}]'
In addition, I use two flows which consists of "anthn/Password" and
"authn/Totp".
"Auntn/Totp" is one I developed.In this case,Office365 requires to pass
both flows.
(1) To enable above-mentioned flows, I defined idp.properties as follows.
idp.authn.flows= MFA|Password
idp.authn.favorSSO = false
(2) I defined /opt/shibboleth-idp/conf/relying-party.xml as below.
<bean id="PasswordPrincipal" parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
/>
<bean id="TotpPrincipal" parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Totp" />
<util:list id="shibboleth.RelyingPartyOverrides">
<bean parent="RelyingPartyByName"
c:relyingPartyIds="urn:federation:MicrosoftOnline">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO"
p:disallowedFeatures-ref="SAML2.SSO.FEATURE_AUTHNCONTEXT">
<property name="defaultAuthenticationMethods">
<list>
<ref bean="TotpPrincipal" />
<ref bean="PasswordPrincipal" />
</list>
</property>
</bean>
</list>
</property>
</bean>
</util:list>
(3) I defined /opt/shibboleth-idp/system/conf/general-authn-system.xml as
below.
<entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:Totp" value="125" />
(4) I defined /opt/shibboleth-idp/conf/authn/general-authn.xml as below.
<!-- Add TOTP -->
<bean id="authn/Totp" parent="shibboleth.AuthenticationFlow"
p:passiveAuthenticationSupported="true"
p:forcedAuthenticationSupported="true">
<property name="supportedPrincipals">
<list>
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Totp" />
</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" />
<bean parent="shibboleth.SAML2AuthnContextClassRef"
c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:Totp" />
</list>
</property>
</bean>
</util:list>
2019年2月3日(日) 16:22 Rod Widdowson <rdw at steadingsoftware.com>:
> Did you chase up why this
>
> >
> [INFO]net.shibboleth.idp.saml.nameid.impl.AttributeSourcedSAML2NameIDGenerator:227]
> - Attribute sources [ImmutableID] did not produce a usable identifier
>
> Happened? You’ll need a log of the attribute resolution. My guess would
> be that the principal is different in the two cases and when you present
> that to LDAP it doesn’t resolve...
>
> Rod
> --
> 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/20190204/ef8c112c/attachment.html>
More information about the users
mailing list