Federation is the way of the future in these scenarios. I'm spending about 50% of my time at work these days helping to build out our federation infrastructure and imagine that we'll be using it extensively. We are already doing some type of federation thing with over 30 vendor-hosted apps internally (benefits, travel, surveys, etc.). However, none of these implemenations are currently using any of the standard federation protocols (SAML, WS-Fed) and suffer from expensive implementations, no reusability between implementations and dubious security.

We are also looking at hosting some services internally for clients and partners and using federation as a way to allow them to authenticate with their own credentials.

The big challenges right now are that with both SAML and WS-Fed as the dominate protocols out there (and WS-Fed much further behind in terms of adoption rates, but gaining due to the popularity of AD and the low cost of ADFS compared to many solutions), it is hard to say you only want to do ADFS/WS-Fed. Our approach is to try to support both for the "outbound" scenario, where our users are accessing a partner resource, although we are still trying to pick a SAML 2 product yet. We'll probably be more picky about WS-Fed for the opposite scenario as our guys like to use Windows token-based websites (like SharePoint) for custom dev and only ADFS has a really flexible solution for supporting this.

The big challenges are that right now, things are still pretty "early adopter", so it is hard to find a lot of partners that are ready to go with their infrastructure. There isn't much expertise out there with these products yet either, so people are stumbling quite a bit. In our "inbound" scenario, we are looking at needing to set up an alternate account store to host the accounts of partners who aren't "federation-capable" yet, so that's a drag. I'm not sure the team building that app has realized yet that the cost and complexity of the identity and access management work for that account store will likely outstrip the cost of dev and maintenance on the app itself by an order of magnitude. They aren't I&AM people, so they are just realizing that users of the store will need features like password change, password reset and password expiration notifications. BTW, we are using ADAM for the account store and setting it up as a separate federation account partner.

Another thing worth noting is that we already have a well-established process for provisioning accounts for external users and contractors in the corp forest and we'll continue to use that in scenarios where it is appropriate. However, we'll try to do as little as possible of that sort of thing when simple access to a few web apps is all that's needed.

All in all though, I'm pretty excited about the technology, especially ADFS. It combines my three favorite tech things, I&AM, web programming and .NET, so what's not to love? :)


Joe K.
----- Original Message ----- From: [EMAIL PROTECTED]
To: ActiveDir@mail.activedir.org
Sent: Saturday, July 22, 2006 12:05 PM
Subject: [ActiveDir] Managing Third-Party Users


My trusted directory resource,

I don't remember if this came up on a previous post. but don't recall seeing the topic. As things become more and more integrated w/ some form of ldap authentication against a common directory, the necessity for managing outside vendors, contractors, etc is becoming a larger and larger task. If you're in a situation where the vendor has a large population of users that require access . with incredible churn, this becomes a big issue.

I'm curious what, if anything, anyone else is doing to use some sort of federated system so that user management is left at the hands of the third-party companies. I'm curious also if anyone is aware of any consulting groups that have done this sort of thing w/ an agnostic approach that can fit most environments. I'd love to get an idea of where the industry is heading with this sort of thing. I'm sure the topic probably came up at DEC which I didn't have the luxury of attending.

Thanks all!

marcus c. oh | cox communications, inc. | 404.847.6117 | marcusoh.blogspot.com


List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx

Reply via email to