1

I'm implementing Spring SAML in an app which is configured with multiple identity providers. My IdP metadata configuration has multiple ExtendedMetadataDelegate with an HTTPMetadataProvider and alias for each IdP. The app chooses which provider to use by extending SAMLContextProvider in a similar way to this.

When an IdP sends authorisation my app needs to know which IdP it came from (different providers have different security authorisations). I'm doing this as the docs suggest and using a custom SAMLUserDetailsService and the SAMLCredential.getRemoteEntityID() to determine which IdP made the request.

My question is, can I rely on the remoteEntityID to identify the provider? What if one IdP provider updates their metadata to include a different entityID or even "forged" entityID which was identical to another provider? Wouldn't it be better to use the peer alias as defined by us?

I'm new to SAML so it's very likely my understanding of some basic concept is incorrect, I just want to make sure I'm not opening a security hole with this configuration.

Community
  • 1
  • 1
Wilson Waters
  • 603
  • 5
  • 11

1 Answers1

0

This is a good question. I didn't know the answer so I tried it out.

I have in my test environment an instance of MS ADFS and and SpringSAML project with a Service Provider and Identity Provider configured (for ADFS). In my custom SAMLUserDetailsService I use SAMLCredential.getRemoteEntityID() to determine which IDP the request came from.

I performed a successful login, then changed the name of the ADFS EntityID, then tried to login again. This resulted in a AuthNResponse;SUCCESS;127.0.0.1 message in the logs, but an error in the browser. I ran through it again with debug enabled in the UserDetailService and found that the request is failing somewhere before it gets to the UserDetailService, however, I'm not seeing any error messages in the logs.

To answer your question, (and perhaps someone else can answer more definitively), SpringSAML handles this scenario appropriately in that it errors out. It does not in that there is no error message in the logs. I assume this is because it's a somewhat unusual scenario to happen, or just a bug.

As far as forging another Identity Provider's Entity ID, the SAML requests are signed and therefore anyone trying to forge and IDPs message would also have to have access to their private key.

Lastly, the alias is not in the request, thus it cannot be used to differentiate between IDPs.

blur0224
  • 972
  • 8
  • 26
  • Good idea with testing. And nice to know it given an error. Do you use `HTTPMetadataProvider` to load your IdP metadata?' – Wilson Waters Jul 17 '16 at 12:46
  • I still think it might still be possible to forge a request under this (probably quite unusual) scenario. Given we trust multiple IdPs (potentially hostile against each other), if one were to attempt to forge an entityID of another provider by changing their own metadata (which gets reloaded on my side by `HTTPMetadataProvider`) then we would have multiple metadata entries with the same entityID (maybe not possible?). Requests from either IdP are still signed and accepted as we trust them both. The only way to know for sure is to try it out! – Wilson Waters Jul 17 '16 at 13:22
  • To me it just seems unsafe making authorization decisions based on an id the provider defines (i.e entityID) when we can easily take any risk away by basing the decision off an id we define (i.e. alias). – Wilson Waters Jul 17 '16 at 13:23
  • I've implemented a custom AbstractReloadingMetadataProvider that loads the metadata from a database so I can add/remove IDPs on the fly. It is not possible to use the alias. The SAML specification does not include the internally defined alias the the SAML requests, thus by design, the only option is the entity ID. The signing of the requests ensures it cannot be forged and the request will fail before it gets to the detail service. The test mentioned above simulated someone changing their entity ID to another IDP and it fails before getting far enough to work. Hope this helps. – blur0224 Jul 18 '16 at 11:44