We have an existing multi-tenant SaaS application (ASP.Net MVC), that currently uses ASP.Net Identity (simple user / password encrypted and stored in our database). We have full user management capabilities, whereby customers can manually add users to their own tenant, and specify they level of authorization they have (role based security).
We have a customer who wants their users to able to use their enterprise/windows email/password to log in to the application. Only a small subset of their AD users will have access to our application, so they will still want to use our application to give users access. We just don’t want to store the password in our database anymore. I imagine this will involve hooking in to their AD or ADFS. I have read the article on how to set up the connection between Auth0 and their AD/ADFS and it seems pretty simple.
What I don’t know is how we should integrate Auth0 with our existing application. We want to continue to use our application to add/delete users. All we really need is to use Auth0 to handle the password authentication with AD / ADFS. Do you have any samples / documention explaining how to implement this? All I have been able to find is examples that show the full Auth0 integration, where users a added/managed/deleted via the Auth0 web site.
If my description of our requirements are not clear, let me know. Its getting very late here and I am not sure if I am making sense!
A minimal solution that would meet the requirements you mention could be accomplished by:
Configure an AD or ADFS based connection that targets your customer Active Directory.
Configure your application to allow applicable users to login through the connection configured above.
Implement a rule that for users that authenticated through the AD/ADFS connection also check that an associated user record exists at your database.
The previous approach assumes that:
Your database saves something that the Auth0 rule can use to check if the AD user that authenticates matches one of the existing users (you could do this by username/email).
A rule can make a request to your database; you may need to configure firewall or go through an API that proxies the access to the database.
With this you can then not store Active Directory users passwords on your database, but you can still manage the accounts through your application as the rule will ensure that only the Active Directory users that have a matching account are granted access.
Yes, it can be done also at your own application. However, doing it from a rule means it can more easily be reused across applications and you would also be sure no tokens would ever get issued.
I’m trying the same approach as @cmn002 (authenticate via ADFS and retrieve the user record from another connection/db in a rule).
From a iOS client, I used /oauth/token to authenticate, but looks like the rule is never invoked and I got this error returned to the client { "error": "invalid_grant", "error_description": "Invalid Token" } .What token is this error referring to? Does Auth0 expect a token?
I cannot also find a way to test this on Auth0 dashboard. When I “try” ADFS on the setup page, I got redirected to our ADFS URL and didn’t have a chance to enter credentials.
I’m trying the same approach as @cmn002 (authenticate via ADFS and retrieve the user record from another connection/db in a rule).
From a iOS client, I used /oauth/token to authenticate, but looks like the rule is never invoked and I got this error returned to the client { "error": "invalid_grant", "error_description": "Invalid Token" } .What token is this error referring to? Does Auth0 expect a token?
I cannot also find a way to test this on Auth0 dashboard. When I “try” ADFS on the setup page, I got redirected to our ADFS URL and didn’t have a chance to enter credentials.
Getting the user from another Auth0 connection would not be the same scenario as above; the above was basically an authorization check that you could either do in a rule or in the client application itself; that check implied that the end-user would have to have valid AD credentials and an existing account at the client application. In addition, /oauth/token can be called for different flows and some like the refresh token one do require a token. You should ask your own question and provide more information besides just the endpoint being called.