authentication/ authorization schema

Question

is there any best practice data model for authentication/ authorization schema

Answer 1

The single most important thing is

Do Not Store Passwords

Store digests of passwords. See RFC 2069 and this Wikipedia article. When someone tries to authenticate, you compare the digest of their input to the digest you have to see if their credentials match.

Answer 2

A data model that consists of a mapping of roles to privileges is fairly flexible and suits most purposes.

Then you assign roles to users (the concept is essentially the same as that of groups)...a user may have more than one role, and their role(s) define the privileges they have.

In the code, you check (via their roles) that the user holds the required privilege to perform a function.

Authentication is separate, that's just validating who the user is, not what they can do. Usually you should maintain this separation (though there are schemes that are designed so that they only care what the user can do, not who they are).

In your design you can visualise the access control system as a matrix (roles to privileges).

I would also expand on the 'do not store passwords' answer - don't design your own authentication scheme at all. You'll probably get it wrong. Reuse one that is proven.

Answer 3

I'll add a caveat to S.Lott's answer of "Do Not Store Passwords: Store digests of passwords":

If you really want to protect against attacks, make sure you use salt in the digest; if it's a well-known algorithm like MD5, and someone can get hold of the hash output, then on their own CPU time they can rapidly check against possible passwords and if they find a match then they've got the password. Adding salt prevents this kind of attack (see the wikipedia article).

You might try looking at OpenID as it's a fairly straightforward means of handling authentication. Well-known sites (OpenID providers) handle the authentication for you, and cryptographically assert that the person with identity X has properly authenticated. Then you just need to handle the authorization of which identities X are allowed to do what. You can always restrict which identity providers you trust (e.g. you might trust Yahoo and AOL and Blogger but not some random site since anyone technically can host their own identity provider server).