ID Field in Token

Question

I just have a general question about federated authentication, and this seemed like the best place in the forums to ask it. I'm new to the whole claims-based authentication world (ACS), and there's one piece I don't fully understand yet:  How does the standard 'UserID' field fit into the picture?

At my software company, we're looking at moving our app to the cloud and using a "real" security model for once - and the whole claims-based approach seems like it's the way to go these days (from what I've been reading) - right?. But our code has always relied on the standard 'Users' table and 'UserID' field. In every table in our database, we have a column where we store the ID of the user who created/updated the record.

With the claims-based approach, it seems like there is no ubiquitous UserID anymore. If someone were to log into our software with, say, their Windows account (from a trusted AD domain), I obviously wouldn't have a UserID that I could store in the database.

What is considered to be the "best practice" here? Should we force everyone to authenticate (eventually) against our own custom STS, and include our custom UserID as a claim in the returned token? Or is there some other ID in the token that we should be storing with each database transaction? (PPID or SID perhaps? I'm having trouble just figuring out what those two claims even mean ... doesn't seem to be much documentation on it.) Does each identity provider use it's own unique ID value, like a GUID or something? Or is the idea of a UserID simply old-fashioned, and perhaps there's some better way to do it?

Answer 1

The user in federation is the combination of the Name (or NameIdentifier) claim and the issuer name.

This is what you use to create a unique identifier of the client - you can then translate that to whatever internal userid you are using to hang off data.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 2

Hmm. So what exactly is the difference between Name and NameIdentifier? :) Better yet, as a newcomer to this space, it would be really nice if there were some kind of general reference that explained what all the default claims mean, and how they are supposed to be used. I can't seem to find anything like that on the net.

But suppose I'm starting a new software project from scratch, so I have no legacy compatibility to maintain. What would be the recommended approach? Instead of a numeric UserID field, should I use a string field? And just concatenate the NameIdentifier and IssuerName and store them with each record? Or do I mathematically combine them somehow, such as with RFC2898?

Answer 3

NameIdentifier is strictly speaking not really an attribute statement of the user. It is the value of the subject element in a SAML token. WIF represents those "extra" fields as claims (same for the authentication method and instant claims which are really the authentication statements in a SAML token).

NameId and Name are often used interchangeably. But in my mind NameId is like the "unique user id (relative to the issuer) - whereas Name is often a display name.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 4

OK, Name and NameId are becoming clearer in my head. But by including my UserID in the NameIdentifier claim, I still feel like I'm tying my RP to my specific IP.

Shouldn't my RP be blissfully unaware that there is a specific NameId in the provided token? Isn't there some other, more generic claim that my RP should be storing in the DB instead? I obviously need some kind of data that shows who changed the record in the database; but I don't want it to necessarily be an ID from my Users table. It could have been someone from a trusted AD domain for example. What claim do I store in the DB in that case?

Answer 5

NameId + Issuer is the unique name of the user. Not sure what's wrong with that.

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 6

So just to make sure - you're recommending that I simply concatenate the string values from those 2 claims, and store the result in a string field in the DB? I was wondering about that, but just wanted someone smarter than me to confirmation that direction before I started down that road. :)

So then my last stupid question in this thread is, where do I get the 'Issuer' data? I don't see a claim type for it, is there some other way to get that info?

Answer 7

You're looking for the IdentityProvider claim returned in the token from ACS.