locked
Why Is RequestedAuthnContext=minimum Forcing FBA? RRS feed

  • Question

  • I'm hoping someone can help with this scenario. We are trying to establish a new trust with a new service provider using SAML-based SP-initiated requests.  For some reason, seamless WIA authentication and/or Kerberos to our ADFS farm (Server 2012 R2) is not functioning for this trust.  Users are always presented with the ADFS login page to enter their userid/password.  I can see the service provider is setting RequestedAuthnContext to minimum and are specifying an AuthnContextClassRef of PasswordProtectedTransport (see below). 

    <samlp:RequestedAuthnContext Comparison="minimum">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    </saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
    </samlp:AuthnRequest>

    With RequestedAuthnContext set to minimum shouldn't ADFS still be able to use WIA authentication since it is considered more secure?  The service provider doesn't want to change the code on their end, so how can we get this trust relationship to seamlessly authenticate for our users when they're within the intranet?  Is there anything we can do at our end within ADFS?

    Friday, November 25, 2016 6:24 PM

All replies

  • What do you have in the AuthnRequest section (IsPassive and forceAuth)?

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, November 26, 2016 3:53 PM
  • I don't see where that is specified.  Here is the full decoded AuthnRequest (with URL's masked):

    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_0f5ad528-4e04-462a-91ab-87933fb495a4" Version="2.0" IssueInstant="2016-11-22T18:21:00.991Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://app.web.com/login/sso/saml/consume?customerId=123">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://www.app.com</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true"></samlp:NameIDPolicy>
    <samlp:RequestedAuthnContext Comparison="minimum">
      <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
    </samlp:AuthnRequest>

    Monday, November 28, 2016 1:44 PM
  • Hey Jacob352,

    Have you checked that your AuthenticationContextOrder is set to the default ordering?

    This is the output from my default ADFS server

    get-adfsproperties | select -expand authenticationcontextorder | select -expand absolutepath
    
    oasis:names:tc:SAML:2.0:ac:classes:Password
    oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    oasis:names:tc:SAML:2.0:ac:classes:TLSClient
    oasis:names:tc:SAML:2.0:ac:classes:X509
    federation:authentication:windows
    oasis:names:tc:SAML:2.0:ac:classes:Kerberos

    Good Luck,

    Shane

    • Edited by Shane Wright Monday, November 28, 2016 6:25 PM Weird copypaste issue
    Monday, November 28, 2016 6:15 PM
  • Thank you for the input, Shane.  Yes, I did check this, and it seems to match your order.

    oasis:names:tc:SAML:2.0:ac:classes:Password
    oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    oasis:names:tc:SAML:2.0:ac:classes:TLSClient
    oasis:names:tc:SAML:2.0:ac:classes:X509
    federation:authentication:windows
    oasis:names:tc:SAML:2.0:ac:classes:Kerberos

    Monday, November 28, 2016 6:33 PM
  • I don't have a lab to repro but a colleague had a similar issue recently...

    The temporary findings are the following:

    • The IDP initiated flow would work for this scenario. You can try it out, and eventually play with the RelayState and "smart links ".
    • The SP initiated flow does not allow WIA as a higher option for FBA with the minimum parameter set. It is password based or certificate. You can try it out, enable certificate authentication and see whether or not the user get a cert auth message.

    If you can validate that, maybe we're into something...


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Monday, November 28, 2016 7:05 PM
  • Thank you, Pierre.  Unfortunately, I don't have a lab environment either--just production.  But, I did enable certificate authentication as a third method temporarily, and that seemed to change the FBA login screen.  I still receive the "blue" ADFS login page with boxes for username and password.  But, that added a hyperlink below for 'Sign in using an X.509 certificate' in addition to the hyperlink that was already present saying 'Sign in using your operating system account'.

    It looks like IDP initiated will work.  We would rather not pursue this method, though, unless absolutely necessary.  I believe that might introduce some other challenges if the application sends emails with hyperlinks for approvals or other functions, correct?

    I'm a novice in federation.  But, my initial research into the AuthnRequest format and RequestedAuthnContext=minimum led me to believe we shouldn't be seeing this issue.  So, I am very confused.

    Monday, November 28, 2016 8:21 PM
  • I am a little puzzle by the reasons why ADFS does not consider the WIA as a higher method than U/P in the connect of a comparison="minimum" whereas x509 is. I'll try to find additional information on my side too.

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, November 30, 2016 4:03 PM
  • We are experiencing similar issue where SP is passing a minimum condition of password requirement.

    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_BA5824E272177AE821FB56D18537EA94" Version="2.0" IssueInstant="2017-02-26T23:59:44Z" Destination="https://idp.com/adfs/ls/" ForceAuthn="false" IsPassive="false" AssertionConsumerServiceURL="<saml:Issuer>https://SP.com/adfs/services/trust</saml:Issuer><samlp:NameIDPolicy">https://sp.com/login.html?op=op_samlresponse"><saml:Issuer>https://SP.com/adfs/services/trust</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="false"/><samlp:RequestedAuthnContext Comparison="minimum"><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext></samlp:AuthnRequest>

    Provider has turned of this condition on Test Environment and WIA is functioning as expected.

    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_E7B7650F977B1D4E2798B721779CDF4A" Version="2.0" IssueInstant="2017-03-01T04:58:28Z" Destination="https://idp.com/adfs/ls/" ForceAuthn="false" IsPassive="false" AssertionConsumerServiceURL="<saml:Issuer>https://sp.com/adfs/services/trust</saml:Issuer><samlp:NameIDPolicy">https://sp.com/login.html?op=op_samlresponse"><saml:Issuer>https://sp.com/adfs/services/trust</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="false"/></samlp:AuthnRequest>

    Authentication Context Order is default.

    Service Provider has kind of suggest that turning this condition can be a security risk. I don't understand how this can be a risk. Can anyone advice what kind of risk are we exposed to,  if this condition is turned of?

    Thursday, March 2, 2017 4:56 AM
  • Does someone know any update on that topic?

    Thanks


    Regards Alex

    Thursday, August 10, 2017 10:18 AM
  • Hi Jacob352

    Were you able to solve the problem? We have the same behavior in our environment. If we click twice on "Sign in using your operating system account", we are logged in.

    Regards,

    Kaya

    Monday, June 11, 2018 11:17 AM
  • Hello

    It's not RequestedAuthnContext Comparison=minimum that's forcing FBA it's the value of AuthnContextClassRef in the RST (Request for Security Token) from the SP.

    AuthnContextClassRef = urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport tells ADFS to use FBA.

    Hence ADFS honors that request regardless of the order of authentication methods configured in ADFS.

    Monday, December 3, 2018 12:34 PM