0
votes

We hare currently looking into claim based authentication, and testing a custom STS using WIF.

We have been discussing how to store claims in a database. In many simple examples, the claims are stored as simple attributes in a single table (UserProfile for example) having a FK to a User. The claims are then generated, and the claim type is a URL plus column name (for example http://.../claims/email) and the value is of course the value from the database.

But I need more complex examples. Can you share some of your ways of storing claims in the database? I was thinking of something like a table containing all claim types, and a table containing the values for each user (with a FK to the User). But we really need some inspiration here. So anything you can share will be much appreciated. But again, this is a very "flat" structure...

Update

I tried to make a simple model: http://imageshack.us/photo/my-images/690/suggestionn.png/

Sorry, cant post images yet.

I think this is good for simple claims. But what if I have what I call "nested claims". Lets say that a claim type describes that the user has a claim describing his rights to the resource "Personnel" of the claim type "Documents". That can be described using that model, but what if we want to further describe that claim. Say the use has access level 5 to the resource "Personnel". I can't see how that is possible. Any ideas?

1
Claims are a flat structure. They can't be nested. So the claim would be .../Personnel/1 or .../Personnel/5 (i.e. two different claims). Ultimately, it's just a string which you parse on the RP side. - rbrayb
Or you could create a complex type and serialize it like explained here: msdn.microsoft.com/en-us/library/ms734687.aspx. What do you think of that approach? - Kirk
That's WCF which is built around serialisation. I don't know of STS functionality that allows you to pass claims across like this. You can create complex objects on the RP side ala syfuhs.net/post/2011/11/12/Strongly-Typed-Claims.aspx - rbrayb
The idea is to serialize it on the STS side, and pass it in the claim as a resource, no? Then deserialize it on the RP side. - Kirk
Agreed - but the claims are passed in a SAML token and I don't think it has methods for serialisation of complex objects. See social.msdn.microsoft.com/Forums/en-US/Geneva/thread/… - rbrayb

1 Answers

0
votes

Two things you may wish to consider:

Different Relying Parties (RP) can generate different groups of claims for the same user. So you need a RP table which links to the Claims Types.

(Note: You can distinguish which RP via the wtrealm parameter).

Also, claim types can be one-to-many. If there is a type of .../claims/groups and a user belongs to multiple groups, there will be multiple instances of this claim type.

Have you looked at how Identity Server implements this? It uses a SQL DB.