Validate Client Credentials with Active Directory

[nickhoggard]

Good Morning,

In the current implementation of Client Validator, it appears that there is an expectation that the client secret is available within the identity server component. We're using Active Directory as our Client Store, which means that when we authenticate the client (resource owner flow) we do not actually have the credential secret available to compare against the password on the request.

Is there any capability that I've missed to be able to override the default Client Validator behaviour so that we can offload the client authentication step to an external component (AD) rather than doing an in-memory comparison of the passwords?

If not, would it be possible for the authenticate step to be refactored to IClientStore, allowing for custom autentication implementations?

Regards!

Nick Hoggard

[leastprivilege]

I think you are confusing client and user authentication.

[nickhoggard]

Hi - I've done a bit more research and I you are right I was confused - but my confusion was related to the flow being used rather than client vs. user. The credential I'm trying to authenticate is the partner-systems service account, as opposed to the end user, my my understanding is that I should be using the Client Credentials Flow rather than Resource Owner (hopefully I've got that right now).

If I were to ask the same question again but for the Client Credentials Flow would that make more sense?

Regards,

Nick

[leastprivilege]

Client credentials are managed by IdentityServer - are you saying you want to create an account in AD for your partner service account and use Windows authentication to authenticate that external account?

[nickhoggard]

Hi,

Are you saying you want to create an account in AD for your partner
service account and use Windows authentication to authenticate that external account?

Not exactly - we do want to use AD for partner service accounts, but we were not planning on exposign the service using 'windows authentication'.

The assumption I'd made was that the intent is for implementors using this library to replace the InMemoryClientStore with their own data store of clients to allow for runtime configuration - in our case this was going to be AD (internal standards are that AD is the default credential store), but that means that the secret cannot be retrieved for comparison to the user input.

Client credentials are managed by IdentityServer

Perhaps I'm looking in the wrong place. I can see where the InMemoryClientStore configures the ClientName and ClientSecret, but I cannot see any implementation details where this is not stored in the code itself.

I'm hoping I've just missed something here. Worst case scenario we can implement the client store in a local database - this just moves the responsiblity of secret management from AD to bespoke, which is what I was trying to avoid.

Regards,

Nick

[leastprivilege]

OK - I see. Well you'd need to implement your own IClientStore - we already provide that for database implementations (see the EF repository).

For AD you could pull the hashed credential via LDAP and you your own password verification. That's all we have right now.

[leastprivilege]

But basically you are asking for a ValidateCredentials method on the Client - that could be e.g. implemented against an AD account - is that right?

[nickhoggard]

Hi Dominick,

For AD you could pull the hashed credential via LDAP and you your own password verification. That's all we have right now.

Thanks - we'll go with this option for now.

But basically you are asking for a ValidateCredentials method on the Client - that could be e.g. implemented against an AD account - is that right?

Yes - that is the essence of the request. At a glance I'd thought this might be achievable by moving the authenticate step out of ClientValidator and into IClientStore (still to be called from the Client Validator) - but obviously I haven't given any thoughts to the wider implication of this.

Thanks for your help working through this. Sounds like we've got an option to move forward with at this stage using the AD hash.

Regards,

Nick

[leastprivilege]

Hey,

better late than never ;)

this is for you: 3bdd125

[pashute]

@nickhoggard Is it possible that you share your code (with changes to the connection string etc. ) and show how you connected with the AD. I did something but not sure its the best way...

[govardhanpagidi]

@leastprivilege Where can I get sample for user authentication against Active Directory?
I want to achieve AD validation with IdSrv, if AD validation says true IdSrv should return Identity token back to the client app..

[leastprivilege]

don't know ;)

Either use Win32 LogonUser - or try the DirectoryService APIs in .NET - I don't have a sample right now.

[nickhoggard]

Hi @pashute - sorry I no longer have access to the solution I was working on when I logged this ticket, so unfortunately I cannot provide any details on how we approached this in the end.