Re: ADAM - SSO and provisioning considerations

This whole problem you are trying to solve is pretty hard because your
application seems to require its own identity store of some sort. That
makes it a complex undertaking for anyone to use your application because
they need a way to use their existing identity store in concert with yours.
This generally implies some sort of sync process.

ADAM is a nice choice for a Windows-based app because it is easy to package,
has nice AD integration features and scales well, but you still have an
identity integration problem.

Ideally, your app would be designed so that it can leverage an external
identity store completely and not need a copy of each identity in your own
system for custom groups and schema. That eliminates the sync issue. Doing
something like what Microsoft is doing with ADFS and "claims-aware"
applications is actually a good idea for a design pattern here. It probably
doesn't solve everything, but it is worth looking at for ideas.

You could still bundle ADAM as a default identity store for customers that
don't have a central store or don't want to try to leverage it.

Just some ideas,

Joe K.

"Rob Lewis" <roblewis5@xxxxxxxxx> wrote in message
news:1123263226.796532.302670@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>I appreciate the words of wisdom. I'm almost there...but not quite :-(
> I'm sorry if I'm coming across as thick, but as I said, I'm a noob.
> Also, I'm not sure how clear I was about the fact that we are selling a
> product into the market, and that we are considering packaging ADAM
> with that product. We can't do that with AD; and we can't rely on all
> of our customers using AD as their identity store...not all of them do.
>
> In addition, we want to enhance the schema (by adding our own security
> groups among other things). Being a vendor, it's impossible for us to
> access or modify the customer's AD schema. That's one place ADAM may
> fit in.
>
> But none of that amounts to much unless we can configure ADAM as the
> "guy who talks to the rest of the world" for authentication. That's
> the really important part.
>
> In the case where "the rest of the world" is AD, then I can see how to
> make ADAM do that. But what about the case where the customer is using
> some other identity store / authentication mechanism? (A) Can ADAM be
> configured to handle the authentication part in that case? And more
> importantly, (B) How?
>
> Anyone from Microsoft care to chime in? Thanks again!
>
> - Rob
>


.

Relevant Pages

  • Re: ADAM - SSO and provisioning considerations
    ... In this situation, you could use ADAM. ... bind to ADAM and passthrough authentication to AD in order to do the ... You could even leverage the built in Windows SSO stuff this ... they are all in the customer's identity store. ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD Proxy
    ... but ADAM represents another identity store. ... we felt that proxying would be less of an administrative burden. ... Prev by Date: ...
    (microsoft.public.windows.server.active_directory)
  • ADAM performance
    ... We have implemented ADAM as an identity store for our global firm. ... various applications retreiving information about our AD users. ... Klara. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - SSO and provisioning considerations
    ... and that we are considering packaging ADAM ... we want to enhance the schema (by adding our own security ... "guy who talks to the rest of the world" for authentication. ... some other identity store / authentication mechanism? ...
    (microsoft.public.windows.server.active_directory)
Loading