Laura, I'm with you on voting for some sort of SAML protocol support. I'm
pretty sure that there will be a boom in WS-Federation usage in the field
now that ADFS is out, simply due to the fact that AD has significant market
share, ADFS is really cheap compared to most offerings, and it is pretty
easy to get up and running with no code.
Still, there will be plenty of SAML protocol implementations out there, and
being able to interop with them would be nice. At this point, we are
looking at implementing a whole other separate product just to get this as
we are sure we'll need it for some scenarios.
I'd even be happy with some sort of middleware or add-on module or
something, but I'd really like to manage just one trust policy and deploy
one infrastructure.
Joe
----- Original Message -----
From: "Laura A. Robinson" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Tuesday, July 25, 2006 2:48 PM
Subject: RE: [ActiveDir] Managing Third-Party Users
ADFS, at this time, is able to consume SAML 1.1 tokens. It does not,
however, fully support either the SAML 1.1 or 2.0 specifications. ADFS does
not currently construct SAML 1.1 or 2.0 tokens, does not support the rest of
the SAML specifications and does not support consumption of SAML 2.0 tokens.
Having said that, I have been having many discussions with the ADFS product
group on this one for some time and would welcome any input from this list's
participants regarding their thoughts on the subject of whether or not SAML
support is important in ADFS. If you would prefer to e-mail me your thoughts
off-list, please feel free to do so. This is going to wreck my stealth-mode
perusal of this list, but you can send your thoughts to
[EMAIL PROTECTED] and I will collect the feedback and pass it on to Don
Schmidt, with whom I've had a running dialog on this subject for some months
now.
With all that said, any opinions I express are mine and mine alone, do not
reflect the opinions of my employer, etc., yada, yada, yada. :-)
Thanks,
Laura
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, July 25, 2006 3:30 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Managing Third-Party Users
As far as I know, it's partners accessing our resources.
Regarding ADFS, I thought it supported SAML 1.1?
:m:dsm:cci:mvp | marcusoh.blogspot.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Monday, July 24, 2006 9:51 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Managing Third-Party Users
There are a bunch of products in this space. The two primary
protocols to be concerned about are SAML and WS-Federation.
ADFS is WS-Federation only.
Some other products are SAML only and some support both.
A lot of what you want to do depends on your scenarios. Do
you just want to let your users access partner applications
or do you plan to let your partners access your applications?
Maybe you need to do both?
Joe K.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Monday, July 24, 2006 3:50 PM
Subject: RE: [ActiveDir] Managing Third-Party Users
Thanks for your take on it, Joe. I'm finding the same thing
when it comes
to the ideology. It's not baked in very well yet... so
trying to make a
judgment on strategy is a bit difficult. :) I think I'll
start looking
down what Microsoft offers... problem is I'm not even sure what the
competitors are ...
:m:dsm:cci:mvp | marcusoh.blogspot.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Saturday, July 22, 2006 3:43 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Managing Third-Party Users
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
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
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
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
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
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
