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