ADFS SAML Identity provider redirects to service provider with status "Responder"

Question

I am using omniauth-saml to authenticate users on a Ruby on Rails application.

Authentication has worked well, until we stated attempting to work with companies using ADFS (Windows Active Directory).

Our Application is able to route to the ADFS log-in screen, the log-in operation takes place, and when ADFS redirects back to our application, we are presented with the error message:

The status code of the Response was not Success, was Responder

debugging, we can see that omniauth-saml is what generates this message.

digging though the payload sent to our application, the "SAMLResponse" attribute contains a xml document with the following part:

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /></samlp:Status>

which we believe is related to the error message presented by omniauth-saml.

ADFS is noticeable hard to debug, but we believe the following error messages is what is behind this ordeal:

Additional Data 

Protocol Name: 
Saml 

Relying Party: 
https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432 

Exception details: 
Microsoft.IdentityModel.SecurityTokenService.InvalidScopeException: MSIS3055: The requested relying party trust 'https://our-domain/users/auth/saml/metadata' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust. ---> Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
   --- End of inner exception stack trace ---
   at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
   at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
   at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
   at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.


Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="AD FS" Guid="{2ffb687a-1571-4ace-8550-47ab5ccae2bc}" />
    <EventID>364</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000000001</Keywords>
    <TimeCreated SystemTime="2019-10-15T23:15:19.254339300Z" />
    <EventRecordID>1512764</EventRecordID>
    <Correlation ActivityID="{19de3423-ee29-40a8-890d-0080000000bf}" />
    <Execution ProcessID="752" ThreadID="4076" />
    <Channel>AD FS/Admin</Channel>
    <Computer>serve-name.domain</Computer>
    <Security UserID="S-1-5-21-1708537768-1844237615-682003330-107716" />
  </System>
  <UserData>
    <Event xmlns="http://schemas.microsoft.com/ActiveDirectoryFederationServices/2.0/Events">
      <EventData>
        <Data>Saml</Data>
        <Data>https://our-domain/users/auth/saml/metadata?attr1=123&amp;attr2=432</Data>
        <Data>Microsoft.IdentityModel.SecurityTokenService.InvalidScopeException: MSIS3055: The requested relying party trust 'https://our-domain/users/auth/saml/metadata' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust. ---&gt; Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
   --- End of inner exception stack trace ---
   at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
   at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
   at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1&amp; identityClaimSet, List`1 additionalClaims)
   at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String&amp; newSamlSession, String&amp; samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String&amp; samlpSessionState, String&amp; samlpAuthenticationProvider)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.

</Data>
      </EventData>
    </Event>
  </UserData>
</Event>

My understanding of ADFS is limited, so I'm not sure if the errors were caused by ADFS misconfiguration or by something specific we would need to add to our application to make it work with ADFS...

Your help would be appreciated!

score 1 · Answer 1 · answered Oct 16 '19 at 19:12

1

The RP with identifier "https://our-domain/users/auth/saml/metadata" does not exist in ADFS.

How did you configure the ADFS RP? Did you use metadata?

The RP should have the above identifier in the "Identifier" tab when you view it via the ADFS wizard.

answered Oct 16 '19 at 19:12

rbrayb

46,440
34
114
174

the identifier configured is `https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432` I was suspecting AD cannot handle the query strings because this error does not have the query string params, is this the case? – The Fabio Oct 16 '19 at 20:19
It has to be an exact match. – rbrayb Oct 16 '19 at 20:39
the relying party trust was configured with the identifier as an exact match (with the query strings)... these log entries seem to be the only place not having the query strings atm. They make me think AD does not allow query strings for the metadata url on the RP – The Fabio Oct 17 '19 at 01:27
The identifier corresponds to a SAML entityID and I've never seen one with a query string. What happens when you remove the query string? – rbrayb Oct 17 '19 at 01:47
My application currently requires two query string attributes to generate the metadata file. Other Identity providers accept this without issues, just AD is giving us headaches... – The Fabio Oct 17 '19 at 01:58
my suspicion was correct... ADFS does not seem to be able to handle query strings in the metadata url... – The Fabio Oct 22 '19 at 01:14

score 0 · Accepted Answer · answered Oct 22 '19 at 01:13

0

As it turns out the answer was to provide an alternative url for ADFS to retrieve the SAML metadata file from our system.

It seems ADFS cannot handle having query strings into its "relying party trust" "Federation metadata file location" (this ADFS jargon is killing me ...)

anyway, once the url could be used without query strings, all worked fine. We moved the parameters to be part of the url:

instead of

https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432

we monkey-patched omniauth-saml and used a new url so we could provide the same functionality with the alternative url:

https://our-domain/users/auth/saml/:attr1/:attr2/metadata

answered Oct 22 '19 at 01:13

The Fabio

5,369
1
25
55

I would presume that after you made this change, the IdP needed to re-import your metadata again? Or did it somehow "automagically" pick up the changes? – eidylon Feb 24 '21 at 15:51
it was not working with the attributes in the query string, so yes, the idp had to re-import – The Fabio May 07 '21 at 11:42

ADFS SAML Identity provider redirects to service provider with status "Responder"

2 Answers2