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&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. ---> 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.
</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!
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