Re: ADAM - SSO and provisioning considerations

Agreed, although I wonder what the implication would be if you used AD as
the authentication store for the user and groups in SQL for the
authorization?
Is that possible with your product?

I know a little while back I did some work with a company that wanted to
install an OU, do LDAP bind's to AD for authentication, and used some
middleware components to sit between. Wasn't elegant, but they were nice
enough not to extend the schema so I was very willing to go along. It was an
OU and a bunch of groups that they used to permit access to their resources.
I bring this up as an example of how you *could* do this. They were porting
that application from SunOne directories, so there were a few issues, but
nothing unexpected.

The above illustrates why you don't need ADAM. We didn't need ADAM because
there was no need to proxy the directory or the authentication mechanism.
Just the authorization portion of the transaction needed to be different. In
there case, they saw no reason to put that into a separate DB. I don't see
one here either.

What your application does with the information it collects is up to you.
Making it work with AD, ADAM, SunOne, OpenLDAP etc is all possible and would
be fairly consistent with some extra effort. I don't think your clients are
going to mind if you do that, as long as you don't require schema
extensions. If you do, then some will be OK and some won't but for just
about all it will increase the barrier to entry for your sales team and
cause a weakness where your competition can get a toe-hold in your accounts.

I think you're going down the wrong path if you think you're going to walk
into an account and architect a SSO solution for their identity stores and
the third-party applications they buy. You may be able to create an
ecosystem that third-party vendors choose to plug-in to and use as many open
protocols as possible, but you would be nutz if you think you can solve this
problem for them and the customers. Really, you'd be nutz if you created
this solution and didn't sell it as a solution in and of itself.

I see nothing in your posts that indicate you cannot use just about any LDAP
store for your identity store. In some you'll also get SSO like qualities.
Like AD. ADAM buys you nothing but complexity that I can see as long as you
don't need to modify the schema. If you do, it could offer an alternative
to some.

Al Mulnick -MVP Directory Services

"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:uy7WzQfmFHA.3608@xxxxxxxxxxxxxxxxxxxxxxx
> In this situation, you could use ADAM. Essentially, you would use a
> secure bind to ADAM and passthrough authentication to AD in order to do
> the authentication. You could even leverage the built in Windows SSO
> stuff this way. The secure bind mechanism supports supplied credentials
> or using the current Windows security context directly.
>
> You can also create groups in ADAM and add Windows users to them, so that
> might be a good way to solve the groups problem.
>
> You could also leverage ADAM to store user principals that don't have a
> Windows counterpart, perhaps for customers that want to create completely
> separate identities or can't leverage Windows.
>
> Really, the only problem with this would be supporting other identity
> stores besides Windows and ADAM. That would most certainly require synch
> or a different solution.
>
> Joe K.
>
>
> "Rob Lewis" <roblewis5@xxxxxxxxx> wrote in message
> news:1123269685.447381.50130@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> Thanks Joe. You're right - a central problem here is: where are
>> identities stored. What if we use ADAM, but don't store the identities
>> at all; they are all in the customer's identity store. If that store
>> is AD, then no problem. But what if it's not AD? In that case, can we
>> use ADAM to transparently refer the ldap binds? Don't know if that's
>> possible...that's what I'm trying to figure out. If not, then I don't
>> think we can use ADAM.
>>
>> Actually, to fine-tune what it is we're actually trying to do, it's
>> mostly this: the customer already has an identity store (with thousands
>> of users, let's say). When they install our product, their users
>> should be able to use their existing user accounts (and credentials) to
>> access their data in our app (as opposed to having them recreate
>> thousands of accounts on our system).
>>
>> The reason we need our own groups is: admin users of our product can
>> create new groups using our app, and alter membership in those groups.
>> But since they have nothing to do with the organization's global
>> structure, they can't go in AD (or anywhere else outside of our
>> product). However, we don't need to use ADAM for that. It would be
>> nice if we could wrap group membership and authentication together, but
>> I see the group membership problem as much easier to solve. We could
>> continue to use our SQL database for that; especially since our admin
>> users must manually manipulate these memberships anyway.
>>
>> It's the authentication problem that's got me scratching my head...
>>
>> - Rob
>>
>
>


.

Relevant Pages

  • Re: ADAM - SSO and provisioning considerations
    ... ADAM and "custom" security principals and gives you ... for authentication, where you might ship some default providers (ADAM LDAP ... be used to link up to the authorization store. ... > customer's identity store is a non-MS directory, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - SSO and provisioning considerations
    ... single credential store. ... > that app will launch our app, so it can pass the username or SID on the ... ADAM doesn't simplify your architecture from what I can tell in your posts. ... LDAP bind is not an authentication process. ...
    (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)
  • 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: 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)