1

I'm working on setting up a service provider that supports SAML. I've added two identity providers - one custom one that I built from SimpleSAMLphp and then ssocircle. So I log in to the selected identity provider, and then it returns to my service provider and I inspect the attributes of the SAML Auth object. The identity provider I built returns whatever I want it to (obviously). The ssocircle one only returns e-mail, first, and last names.

So now to map this to the user of the service provider, I have to use some value the identity provider provides. So this led me to wonder how it should be done. Since ssocircle only gives me e-mail as a useful value, do I just use the e-mail to map to the SP user?

Let's pretend for a second that ssocircle doesn't validate e-mail addresses. So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges.

So my question is, do I handle this? Or is the onus on the admin who set up the identity provider and say "well you shouldn't have used an identity provider that doesn't validate e-mail addresses!" or something of that nature? Or should I only allow identity providers that pass a certain value, like userid or 0.9.2342.19200300.100.1.1? Is there something that identity providers commonly use?

Andrew
  • 1,571
  • 17
  • 31

2 Answers2

0

Well, you said it, two different identity providers. They both should be passing not only the email but different entity ids and certificates.

In multi-tenant applications that would mean two different applications, but if you plan to allow multiple IDPs to point to a single app you will need to ensure that same email but different entityID create two different users and or throw an error after the first was created that the second cannot be provision nor access.

s1mpl3
  • 1,456
  • 1
  • 10
  • 14
  • I'm not having an issue discerning the two identity providers, I'm having trouble trying to create a single code path for all identity providers. If one provides only an e-mail and the other provides only an id, it seems like I have to go through all identity providers and see what they return and write custom code to accept it. – Andrew Apr 24 '17 at 19:25
  • My response was around "So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges". If you are going to accept two different types of entityID you will need to write custom code. " – s1mpl3 Apr 24 '17 at 20:27
  • I was suggesting I could create two accounts on the same identity provider. Well, you create an account with your e-mail, then I create an account with your e-mail, then I log in as you since the SP just assumes the e-mail is trustworthy even though the idp is really the one that decides. I can see the workaround for different idps, but what about the same one? – Andrew Apr 24 '17 at 20:40
  • I may not be understanding but an IDp should always authenticate each user the same way (ex. email or whatever id you ask them), the objective is to avoid: "So now if I create a second account at ssocircle with the same e-mail, I can log in as my coworker who I know has admin privileges." As service provider same email means same user. – s1mpl3 Apr 24 '17 at 20:50
  • Right, but as the service provider, I don't control how secure or insecure the identity provider is. I'm trying to set up my service to allow users to set up their own SAML idp. Now if they use Frank's Discount Identity Provider that doesn't validate e-mail addresses, suddenly they have a huge security hole. So is the answer "don't use e-mail addresses" or "that's the user who set up the idp's problem"? – Andrew Apr 24 '17 at 20:58
  • I don't quite understand the "allow users to set up their own SAML idp" part but if allowing ex. Franks' Discount IDp compromises user information it can become your problem. You should verify who the IDps are. Ex. You autenticate users from company ABC, ABC has been setup with the proper certificate. User bill@abc.com can access now. A second IDP is trying to feed a bill@abc.com. This user will not be considered the same in your application because they should not be using the same certificate. You can create a user account with that email but it should not be the same – s1mpl3 Apr 24 '17 at 21:30
  • But what if *the same* idp sends the e-mail for *a different user*? – Andrew Apr 26 '17 at 21:21
  • IDp is Identity provider, whatever they send is their responsibility to verify. At your end just make sure that user identifiers are tied to each IDp – s1mpl3 Apr 26 '17 at 21:39
0

Interesting question. These days people think always of auto federation of users by some attribute. In early SAML federation days federating two unrelated users was a manual step in which a user logs in at the IDP and logs in to the SP providing both sets of credentials and then manually federated these two user accounts. The process guarantees that only the user who has access to the accounts at the IDP and SP controls the linkage between the two. It also allows anonymous naming identifiers (SAML persistent NameIDFormat) which protects privacy because even the IDP does not know the user name at the SP and vice versa.

Unfortunately the process was to complicated for users and with the success of OpenID the aspect was getting less and less important.

To answer your question: What you describe happens in the real world -see Office 365 authentication bypass

You need to check that the IDP is authoritative to send a specific attribute and attribute scope in case of two IDPs.

In case of one IDP the attribute must be verified (SSOCircle verifies email address) and it should better be unique (For example SSOCircle userId) to avoid that two users with the same attribute are mapped to a single user at the SP. If the userid's are not the same (e.g. you use a simple user ID at the IDP and email address format at the SP) you can still add a correlation attribute at the SP (e.g. an attribute named ssocircle-userid) and use that to link the user accounts.

Hos
  • 447
  • 4
  • 11
  • Frankly, I've found learning about SAML to be a very frustrating experience. It seems like it's a secret handshake nobody wants to be clear about. – Andrew Apr 24 '17 at 17:17