Re: ADAM - SSO and provisioning considerations

I have to say that the scenario you mention is weak at best. That and SSO
(single or simplified sign-on) does not require that the user ever logon to
the desktop OS. It does require unique credentials and can be easier with a
single credential store.

For instance, the desktop could be a kiosk (which by the sounds of it, would
be FAR more secure and in keeping with what they are doing anyway) and the
client would therefore never logon to the OS. They would however, want to
authenticate to get authorization to the data your application is holding.
Today that's done via a SQL call. Tomorrow that could be done via AD
technology. Not a major rewrite in many cases.

> I did get some clarity about the non-WIA case: as it turns out, we can
> expect some level of integration with the 3rd party. In other words,
> that app will launch our app, so it can pass the username or SID on the
> command line and assume the user was already authenticated. Then we
> just need to access our authorization data for that user.

You may want to look into that. It's about credentials. Passing credentials
is documented so that users can run in a certain security context.
http://msdn.microsoft.com would be a good place to look for that
information.

ADAM doesn't simplify your architecture from what I can tell in your posts.
If anything, it complicates your architecture by adding two additional
components you didn't have before. Third party apps can work just fine with
Active Directory. If they can't, then they won't work with ADAM either.
LDAP, NTLM, etc are all handled by AD. (side note: LDAP is NOT an
authentication protocol. LDAP bind is not an authentication process. It is
an identity process that may use an authentication protocol at some point.
Might make a difference later in the architecture.)

Consider it this way: in order to access a network resource, you MUST
identify, authenticate, and authorize an entity to access that resource. If
you place a proxy in front of your AD, you're just adding an additional
identification store in front of your identification store and your
authentication and authorization mechanism. What benefit does that provide?
Oh, and you would also have to synchronize that "proxy" store. Can't
imagine that would be as reliable as you'd want because you now have
introduced another moving part which goes against the KISS principle of
software architecture.

For the reasons you've mentioned, you'd need both ADAM and AD set up to
deploy a bind-proxy object. Not sure what value ADAM provides at that point
other than you would not have to modify the schema of a customer's AD
deployment. That can potentially be a barrier to a sale and you would then
be heartbroken to find out you would have to rearchitect. The customer also
may not be happy to find out they have to deploy your app, sql, Windows 2003
Enterprise, ADAM, etc AND that they have to configure it, maintain it, etc.
I wouldn't be happy about that.

I would be happier if I had the OPTION to deploy this against ADAM or AD,
but I would not be happy to be forced to deploy both if it otherwise made no
sense. I'd likely laugh the sales team out of my office (if I had one any
more ;) and go look at the competition.

My $0.04 anyway.

Al

"Rob Lewis" <roblewis5@xxxxxxxxx> wrote in message
news:1123181533.383276.181650@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Al,
>
> Thanks for the info. Actually, the main reason (that I know of) for
> vendors not choosing AD as their authentication store has to do with
> the working environment. It's the case where PC's are in public areas,
> and are left logged on all the time. The user who walks up to the
> machine needs to tell the application who he is in order to access his
> data. For whatever reason (lazy users...), in those environments, the
> user feels that it's too cumbersome to log in and out of windows.
> They'd rather just launch the desired app, identify themselves, do the
> work, quit and walk away. Of course, if they launch more than one app,
> that's when the SSO issue arises.
>
> I did get some clarity about the non-WIA case: as it turns out, we can
> expect some level of integration with the 3rd party. In other words,
> that app will launch our app, so it can pass the username or SID on the
> command line and assume the user was already authenticated. Then we
> just need to access our authorization data for that user.
>
> Btw, the other reason I was given to use ADAM is to simplify our
> architectural design, since if we need to support talking to different
> data stores (AD, LDAP, SAM, etc), it makes sense to have our apps talk
> to ADAM as a "universal" authenticator, and let ADAM deal with the rest
> of the world. What I don't know is whether that's practical, or even
> realistic. I'm guessing it probably is. Basically, my app needs to
> bind to ADAM, passing credentials if they were supplied. If not, it
> passes null credentials, binding as the domain user. Correct? The
> trick appears to be getting the identity info into ADAM at the time a
> user is provisioned, and telling ADAM where to go to authenticate.
>
> FWIW, I should say that I've gotten ADAM setup on XP, gone through the
> step-by-step and gotten bindProxy to work. At this point, I'm just
> trying to work out a few top level details before we go to design
> review.
>
> - Rob
>


.

Relevant Pages

  • Re: ADAM - SSO and provisioning considerations
    ... install an OU, do LDAP bind's to AD for authentication, and used some ... The above illustrates why you don't need ADAM. ... store for your identity store. ... they are all in the customer's identity store. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - SSO and provisioning considerations
    ... vendors not choosing AD as their authentication store has to do with ... For whatever reason, in those environments, the ... They'd rather just launch the desired app, identify themselves, do the ... the other reason I was given to use ADAM is to simplify our ...
    (microsoft.public.windows.server.active_directory)
  • Re: What is the best approach to the following situation?
    ... authorization system that derives role information from some sort of store. ... users in your ADAM store and create application-specific groups in ADAM that ... you simple use an ADAM LDAP bind for your Forms authentication ... application-managed authentication and authorization in web applications. ...
    (microsoft.public.windows.server.active_directory)
  • AzMan + ADAM + ASP .NET 2.0 problems
    ... I have a web app written in ASP .NET 2.0 which uses AzMan as authorisation ... On the test server, though, I have installed ADAM and created an AzMan ... store there. ...
    (microsoft.public.windows.server.active_directory)
  • AzMan scope level application groups seem to be broken
    ... I have an AzMan store in an ADAM instance using ADAM principals. ... If I assign an ADAM principal as a member of either a store or app level ... if I assign a principal to an application group at the scope level ...
    (microsoft.public.dotnet.framework.aspnet.security)