Directory Programming .NET

Hi,

I'm pretty new to ADFS, but I do have it up and running successfully in a couple of my ASP.NET apps. I have a problem with an ASP.NET custom RoleProvider, and I'm having trouble finding an answer to this question because the problem spans both ADFS and ASP.NET. But I hope someone here can help....

I've just written a simple custom RoleProvider and it functions correctly in my ADFS apps. However I'm running into a problem with the RoleProvider's IsUserInRole() and GetRolesForUser() methods. Both these methods have a parameter named username. This is the value I have to then use to uniquely identify the user and look up their roles. The value sent into this parameter (by the ASP.NET RoleProvider mechanism) appears to be from the SingleSignOnIdentity.Name property. The value in the SingleSignOnIdentity.Name property appears to come from the AD value of UPN. This is a problem, because I'm in a very large coporation with multiple forests and the UPN is not guaranteed to be unique across forests (for example, we use the user's email address for the UPN value, so it's possible someone with an account in each of our forests puts in the same email address in both accounts). So it's a security hole if I use UPN.

So my questions are:

1.) Are my assumptions right as to where these values come from?

2.) Wherever it comes from, can I map some other value in ADFS that will eventually show up in these RoleProvider's method parameters (username)? Ideally I'd like to use the user's SID, because it's guaranteed to be unique. Or if that's not possible, could I possibly map a concatenation of domain\username to it?

It's difficult to frame these questions to an ADFS audience because I don't know exactly where ASP.NET gets the value of the SingleSignOnIdentity.Name property, so I can't ask the question in strictly ADFS terms. So I'm hoping someone out there is familiar enought with the ASP.NET side of this (SingleSignOnIdentity) to help.

Thanks in advance!

Buzz

 

You may not realize it but you ask many other implicit questions. And the answer is that it depends on many things.

What is in SingleSignOnIdentity.name?
If you are running standard ADFS with a "Claims Aware" application (NT Token is different), then SingleSignOnIdentity.name normally contains whatever the resource ADFS server has put in the SAML token. On the WEB server it is put there by System.Web.Security.SingleSignOn.WebSsoAuthenticationModule.
If you want to see the SAML token then probably the simplest method is turning on logging in the resource ADFS server. There you see incoming and outgoing SAML Tokens.
Look for the XML as below.


username@what.ever.domain



Next question would be: "What goes into the SAML Token?".
That depends on many things. It depends on what is sent to you (if it comes from account partners) or what is in the AD (if the account is in the AD of the resource ADFS server) and what is configured to be passed to the application.
It is possible to influence that through configuration. Or if that is not good enough, then you could, in theory, make a CustomClaimTransform (implement IClaimTransform).

Now about your name uniquenes problem.
If you cannot differentiate between users, then you are lost!
At the WEB application side SingleSignOnIdentity.AuthenticatingAuthority property may help. In a Custom Transform, the "issuer" parameter of the TransformClaims method may do it for you.

Whoops my xml was lost....
saml:AuthenticationStatement/saml:Subject/saml:NameIdentifier