Directory Programming .NET

TechNet has a nice Step-By-Step for a sample claims-aware app, but when I try to arrive at a sample token-based app using a Resource Group, I get stuck! Does anyone know of anything written down (other than the TechNet "Checklist" for token app)? Joe, I love your book and it's time for an ADFS title!
-Byron

Not sure what you've already seen versus what you're looking for, but this is pretty good as an examplar: http://blogs.technet.com/adfs_documentation/articles/444865.aspx I'm trying to convince Joe to write an ADFS/Geneva book with me. He's unswayed thus far. ;-)

I love the idea of book but I'm uncertain I would actually succeed at getting it done without getting fired.  It all seemed much easier before I had two young children.  :)

Are you talking about a token app that uses "shadow groups" to generate the token?  If so, that one is a bit of black magic but it can be done.  Otherwise, please let me know more details about what you are trying to do and what your layout is with account partners/IdPs, etc.

My end game is a bit insidious: I'm trying to simply read the UserPrincipalName using legacy ASP sitting inside a ADFS web agent protected website. But perhaps you can cut to the chase: if I use a mapped resource group (as opposed to individual accounts)mode, can I find the UPN text anywhere in the HTTP header? Or will I only see the shadow account that is used to spin up the access token?

See! That's why I need a book....I had buried that link in a sea of other links. Thanks for the reminder.

It depends.

First off, for users in the account store for the resource FS itself, the ADFS agent will always just create an NT token for that specific user from the resource AD forest.  In something like ASP, you'd just read a server variable like LOGON_USER to get the Windows logon name.  There is no way to use the shadow groups feature for principal mapping

For users from an account partner, for the token agent you need a mapping strategy.  You can either map to specific users or you can map to groups only.  In the case of the groups only, the user will have the logon name associated with their primary identity claim (could be the UPN) and will have grups in the token that match resource groups in AD that align with group claims in their SAML token.  So, you could use this mechanism to discover the user's identity in ASP by looking at LOGON_USER again.

It is a little tricky getting shadow groups to work and it is also a bit fragile, but it does actually work.

Ideally there would be some agent that was more like the claims agent in that it takes no dependency on windows security but runs at the web server level like an ISAPI filter/extension which just published the claims as HTTP headers so you could read them from any app.  However, MS didn't give us that with ADFS.  I think you can do stuff like that more easily with Geneva and IIS 7 in integrated pipeline mode though (although I haven't tried).

If the shadow groups thing is what you are trying to do, I can help.

The first step it getting a group claim to flow all the way from the account partner to a resource app.  If you can get that working with a claims aware app, getting the token mapping stuff to work after that isn't too hard.

I'm getting the warning in the adfsweb Application Log that the ADFS Web Agent ISAPI was unable to obtain a Windows NT token from the auth service, and therefore only getting an anonymous token. I see that the LOGON_USER and AUTH_USER are empty in the web app and I'm assuming that's because of the anonymous token.

I see in the adfs verbose log on FS-R where it mentions the GroupClaimTransform from in-coming claim to GroupSid, but one entry says "called" and the very next entry says "did not apply". That's wierd...

The four VM's are working fine for the Claims-aware app, so the trust policy, certs, etc. should be fine.

I'll try the resource account mode to see if I can get past this dumb-down to anonymous.

In your claims app, do you have a group claim being generated for the authenticated user?  Generally speaking, the steps are:

• Ensure the user in the account FS is actually IN a group that has a group claim AND an extraction defined
• Make sure the resource partner configuration is configured to send the group claim to an agreed on name to the resource partner (they aren't sent automatically)
• Make sure the resource partner has a org claim defined for this group AND it has a Windows resource forest group associated with it (not the same as the claim extraction from the resource FS account store!)
• Make sure the inbound account partner config maps the group claim from the agreed on name to the defined org claim
• Make sure you use the "groups only" option for the account partner configuration (the ones where it will also try a user if group doesn't match just make debugging too hard since it tries too many things)
• Make sure the org claim is actually enabled for the app (easy to miss) in the resource FS!

If you did all that, you should be able to get a group from the user in the account FS into an app in the resource FS.  The test claims app is a good way to verify that the flow actually works.  For the token app, as long as the org claim is also enabled, the "groups only" mapping option is used and the org claim has a resource group defined, it should work.

My experience with this is that as the resource partner, it is basically impossible to ensure that the AP admins will guarantee that the user will always be in at least one group.  As a result, this makes your app potentially quite fragile since that anonymous token basically breaks your app.  As such, you might consider implementing a custom claim transform that inserts a group claim for all users coming in so that they'll have at least one group all the time to ensure you always get a valid token.  Something to consider...

 

SUCCESS!!! I had forgotten one little step...the Group Claim Extraction on the Account side. Thanks Joe, for your help. Enjoy the weekend with your kids.

agree re please write a current adfs book - the timing is right :)

re nt token - we are implementing the example per link in this forum, but doing so in a single domain with a single fs server.  our goal is very simple, basically to use ADFS as an alternative to Forms Auth in order to present a 'friendlier' site and app customizable adfs logon page, in place of basic auth/ssl popup.  we want the app to continue to run as the logged on user (secure, auditable), and continue to apply system ACL security and 'iscallerinrole' type processing based individual group memberships.  

after getting all the certificates set up right (which is fun), we still couldn't get the adfs ls logon page to come up.  it kept bringing up a basic auth prompt even tho the workflow logs showed it was hitting the fs server. 

it turns out the nt token documentation assumes a proxy server, and the logon aspx file has to be manually copied over to the fs server if using a single server scenario. i've pasted the detail received from Fareed Muhammad Khan [fareedmk@microsoft.com] (below, fyi).  also got some nice help and further info from joe (thanks joe).

you can probably email fareed if you want the attachments referred to in the note below, or do the test install per script with a proxy server, and then copy the file from the proxy server as noted.  at this point its working in our testlab and we can customize the logon form for the enterprise and include per-app instructions based on the http referrer.   here's the info from fareed