views:

36

answers:

1

Simple situation. An existing project will need authentication and authorization and I need to design it. First of all, I choose to divide the whole thing into two modules, one for authentication and the other for authorization. Both will be seen as blackboxes for the project. For now, the authentication module will just use the Windows account of the user, link this to an unique GUID and offer this GUID to other modules as the user ID. Newer versions of this module will do more "magic" but for now, this will be enough.

The authorization module will be a bit more complex. It will use the GUID and link it to the access rights of the user. With the GUID, it could communicate with the authentication module and request more user information.

But next to roles, should the authorization module also manage some other user data, or would it be better to add them to the authentication module? (Think about name, address, phone, office name, gender and how they like their coffee...)

Basically, the authentication module will contain an interface and customers who like to use our software can use out default authentication module or use the interface to develop their own version. So I don't want it to keep too much information.

And would I need more information in the authentication module than just the roles?

+1  A: 

If the applications using the authentication benefit from shared information, such as change in email address, it could be stored in the authentication system. In fact, the authentication call can be implemented as retrieval of the user information along with some credential such as password.

Authorization (roles, access rights, etc.) on the other hand could be more specific to the individual application and its capabilities.

eed3si9n