6

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?

TonyTon
  • 61
  • 1
  • 1
  • 3

5 Answers5

5

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.

Steve
  • 15,155
  • 3
  • 37
  • 66
  • Would "role-based authentication" per (http://en.wikipedia.org/wiki/FIPS_140) would not use passwords, since as you say passwords are tied to identities? – TonyTon Jul 03 '13 at 09:03
4

"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.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • It seems that "role-based authentication" term is used by the FIPS140 standard. Per [Wikipedia reference](http://en.wikipedia.org/wiki/FIPS_140) "FIPS 140-2 Level 2 adds requirements for physical tamper-evidence and role-based authentication." – TonyTon Jul 03 '13 at 08: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 03 '13 at 17:36
2

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.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • This Wikipedia entry uses "role-based authentication" and "identity-based authentication" (http://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 03 '13 at 08:58
0

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).

Steve
  • 15,155
  • 3
  • 37
  • 66
Jason
  • 1
0

The original question appears to refer specifically to the TCG Jade(Enterprise)/Opal/Ruby authentication system (PIN only, no username). I am working on FIPS 140-3 qualification of a TCG Opal SSD so my answer is specifically for this use case. From FIPS:

AS04.57: (Operator authentication — Level 2) A cryptographic module shall at a minimum employ role-based authentication to control access to the module.

AS04.58: (Operator authentication — Levels 3 and 4) A cryptographic module shall employ identity-based authentication mechanisms to control access to the module.

I believe that the TCG authentication system can be considered either role-based or identity-based. So, if you are attempting Level 2 certification, call it role-based and then all the identity-based FIPS requirements become NA. If you are attempting Level 3 certification then call it identity-based in order to qualify for level 3 certification.

This may sound glib but the difference appears to boil down to how many individuals get the PIN. If only one individual gets each PIN then you can claim that the PIN gives you the identity of the individual. If multiple individuals get a PIN then the PIN is a role that is being performed by multiple individuals and the PIN is for the role.

So, if you are attempting Level 3 certification of your Opal SSD you would need to put the restriction of one individual per PIN in your security policy in order to claim the Opal PIN authentication system is "identity-based".

However, as far as level 3 certification goes, I believe there is a sticky issue with the MSID and the PSID since these are obviously NOT identity-based. This you would have to take up with your lab.

NOTE:

The most recent FIPS 140-3 IG appears to indicate the TCG Opal SSD can only be certified to level 3 if you can prove that the "role-based" authorities (MSID and PSID in this case) do not call any services that affect the module’s security. See IG 4.1.A for the definition of such services.

Burt Wagner
  • 1
  • 1