What is the difference between role-based authentication and identity-based authentication? If a system uses ONLY a password mechanism to authenticate operators (different PIN for Admin and User) it is said to use “identity” or “role-based” authentication?

The system prompts the operator for a password (without asking for a username), then, depending on which password was entered (the User or the Admin) will offer different services for the two roles, or no services if the password does not match.

Is it true that this mechanism can be considered as identity-authentication since IDENTITY can be authenticated based only on knowledge of the PIN?

Moreover, FIPS140 security standard uses the terms "roles-based authentication" for Level 2 and "identity-based authentication" for Level 3 (http://en.wikipedia.org/wiki/FIPS_140). Is the case presented above role or identity authentication per usage in FIPS140 standard?

What are some examples of role-based authentication schemes?


Roles tend to be attached to identities, as you don't authenticate a role, but you authenticate an identity. You can authorize an identity, and you can authorize a role. I believe there might be some confusion here.

A role is an extension of the identity, and it usually works such that (for example) the user 'Admin' has the role 'Administrator'. A user with the role 'Administrator' has different rights than a user with the role 'Standard User'. Identities generally have the capability of having multiple roles, so an administrative user might have role 'Administrator' and role 'Standard User' and therefore has the rights tied to both roles.

Passwords are generally tied to identities, so you are authenticating the password against an identity. If there is no username field, the backend system doing the password validation probably has a lookup that compares all passwords (or more likely just looks up the plaintext of the password) to their associated users.

This assumes that roles are even being used though. If no roles are being used, the authorization is simply against the identity itself; e.g. if user == 'administrator' allow admin things.


"Role based authentication" isn't an industry term. Perhaps you confused it with Role-based access control, which is a method of controlling access to functions based on a users "role", rather than his identity.

For example, a blog system might define an "Author" role and an "Editor" role. An "Author" might have permission to create new stories, but not to publish them. An Editor would have permission to review and modify, and publish existing stories.

Any given user might "belong" to one or more roles on a permanent basis, or might be temporarily granted role authorization during a given session.

But critically, permissions and capabilities are never assigned directly to users, but instead always assigned to roles. Users gain that permission indirectly by taking on a given role. Likewise, a person's credentials are associated with the user account and not the role. Like this:

+-------+    +------+    +------+    +------------+
| human |===>| User |===>| Role |===>| permission |
+-------+    +------+    +------+    +------------+

The system you're describing, with identity and access determined by password alone, is not a role-based system, but instead simply a user-based system without usernames. It's sounds like a particularly bad idea.

  • It seems that "role-based authentication" term is used by the FIPS140 standard. Per Wikipedia reference "FIPS 140-2 Level 2 adds requirements for physical tamper-evidence and role-based authentication." – TonyTon Jul 3 '13 at 8:47
  • @TonyTon FIPS 140-2 describes a system where pre-determined logins ("admin", "guest", etc.) with shared passwords are allowed, presumably because implementing identities in an inexpensive hardware device is impractical. They call this "role based authentication". The standard explicitly states that authenticating instead based on identities attached to roles is more desirable, and required for levels 3 and 4. – tylerl Jul 3 '13 at 17:36

I would say that there is a confusion of terms here.

For the most part this isn't so much authentication as it is authorization. Specifically, you have a scenario where permissions are role-based (an admin set of permissions vs. a user set of permissions) that is protected by a challenge/response authentication mechanism. Because the verification is of a shared password, you're not authenticating individuals, so there is no concept of identity or role-membership per say, at least not an concept implemented in this particular system.

  • This Wikipedia entry uses "role-based authentication" and "identity-based authentication" (en.wikipedia.org/wiki/FIPS_140). There isn't much provided in terms what the difference between the two is, other than the "identity-based" seems to be "more secure". – TonyTon Jul 3 '13 at 8:58

Identity-based authentication is absolutely a "term".

The context here is with HSMs (HW Security Modules) for PKI operations. In role based authentication you have a "password" or smartcard, etc that authenticates the role (like crypto officer, user, etc). Identity based authentication takes it a step further and assigns roles to individual users. E.g. you can have multiple individual users that get the "user" role. Most identity based HSM operations also involve M of N authentication. e.g. there are 5 total users, and 3 have to be present to perform an operation. e.g. M(3) of N(5).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.