Active Directory Authentication with Local-Role-Ba

Question

I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.

For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).

The anticipated flow of control will be:

1. User accesses login page > enters credentials > posts credentials to app server.
2. The app validates the credentials against AD. At this point, we know if the user is authenticated.
3. The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
4. The app will look up roles for the user in the local database user-is-assigned-which-roles table.

User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).

My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).

A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.

Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?

Answer 1

I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.

I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.

My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.

The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.

Answer 2

Please feel free if this can Help You Custom Annotation Authorization

It's only a workaround, or just an idea, not a solution...

To use it you only need to use Annotation in the controller e.g.

 [ARQAuthorize]
public class BlaBlaController : Controller .....