Role-based Access Control Discussion and Proposal
Group Name: SEC WG
Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes
Meeting Date: SEC#20, 09-Nov-2015
Agenda Item: Role-Based Access Control
Background
• The Role-Based Access Control (RBAC) feature has not been completed for
Release-1
• At TP#19, a series of contributions was presented by Alcatel-Lucent (ARC2015-2053/2054, PRO-2015-0884/0885, SEC-2015-0579) trying to
integrate the SRole-ID concept into Access Control Policies (ACP)
– The ALU proposal was not agreed at TP#19, but it triggered further email discussions as
well as a discussion at the SEC#19.2 telco
• At SEC#19.2 following 3 related contributions were discussed:
– SEC-2015-0621 (Oberthur): Presenting several options to map the RBAC model as
developed by NIST to oneM2M access control
– SEC-2015-0625 (LGE): Recap and discussion on Service Subscription Profile
– SEC-2015-0618 (Fujitsu): General discussion on roles and role assignment
– There was no conclusion on any of the above contributions yet
© 2015 oneM2M Partners
SEC-2015-0640
2
Objective of this contribution
• This contribution aims to outline a potential solution which combines the
present Service Role concept (based on SRole-ID identifiers) with concepts
of the original RBAC approach (as specified in the INCITS 359 standard, see
references), applied to the present oneM2M access control mechanism
• We propose to finalize RBAC for the oneM2M Release-2 only
• The solution proposed here nevertheless aims to build as much as
possible on the functionality already included Release-1, without major
changes of existing functionality
© 2015 oneM2M Partners
SEC-2015-0640
3
Current open issues (1)
• serviceRoles attribute of the <m2mServiceSubscriptionProfile>
resource type
– This attribute includes a list of Service Role Identifiers (SRole-ID)
– It defines a set of Service Roles a subscriber is permitted to use based
on his subscription with the M2M Service Provider
– Open issue: if a user/entity wants to act in a specific Role, it is not
clear such role can be authenticated dynamically
• The Role primitive parameter
– Was foreseen to be used to enable indication of a Role dynamically for
each request/response transaction
– Kept as optional parameter in Rel-1 with comment “for future use”
– Open issue: usage of Role primitive parameter needs to be specified
© 2015 oneM2M Partners
SEC-2015-0640
4
Current open issues (2)
• The presently defined Service Roles represent permissions to
create a specific set of resource types
– Resource types are assigned to SRole-IDs by means of a mapping table
by the service provider (as presented as examples in the informative
Annex G of TS-0001)
– This addresses the fact that resource type and instantiation-specific
ACPs cannot be assigned before the resource is created
– This concept does not allow to apply different Roles to different
instantiations of the same resource type. This however should also be
possible with RBAC
© 2015 oneM2M Partners
SEC-2015-0640
5
Present Access Control Mechanism
• Access Control Rules (ACR): originator, operation, context
– Defines which entity can perform which operation under (optionally)
given context constraints
– Present rules do not allow differentiation of access rule for resources
types
• In an M2M system resources are accessed by M2M entities,
not by humans
– There’s no login procedure to an M2M entity where users could take
different roles (e.g. superuser)
– Roles could be entirely mapped to entity ID’s
• i.e. two instances of the same AE implementation may have different AEIDs assigned, enabling the first AE to obtain access to other resources
than the second AE
© 2015 oneM2M Partners
SEC-2015-0640
6
Present Access Control Mechanism
•
•
•
ACPs are assigned to resources by means of resource references
(accessControlPolicyIDs attribute) rather than to include them directly as resource
attribute (as in file systems)
This enables memory savings given the assumption that many resources likely
share the same set of ACPs
However, it likely makes management of ACPs more complex
– ACPs assigned to multiple resources cannot easily be changed
List of IDs in
accessControlPolicyIDs
attribute of Resource_1
Resource_
1
Resource_
2
Resource_
3
ACP_1
ACP_2
ACP_3
ACP_4
...
Resource_
N
© 2015 oneM2M Partners
Instances of
accessControlPolicy
resources (ACP)
SEC-2015-0640
Example:
ACP set = (ACP_1, ACP_2)
assigned to Resource_1
Each ACP includes one
privileges and one
selfPrivileges attribute.
privileges and selfPrivileges
attributes include a set of
access control rules (ACR)
7
Proposal (1)
1.
Associate a specific Role with each AE-ID
–
This resolves the issue of Role authentication: authentication of an AE also
authenticates the Role associated with it
Do CSEs require a Role? Assumption: No
At registration, an AE should indicate the Role it wants to obtain
–
–
•
•
2.
Requested Role is granted if permitted by the serviceRoles attribute of the
<m2mServiceSubscriptionProfile> resource type
Role should be included as resource attribute in <AE> resource type
Organize ACPs such that any ACP is assigned to at least one Role
–
–
–
The Role(s) associated with an AE-ID in the originators parameter
determine(s) to which Role the ACP belongs
This way Roles become equivalent to sets of ACPs
See resulting illustration on the next slide
© 2015 oneM2M Partners
SEC-2015-0640
8
Access Control Mechanism feat. Roles
List of IDs in
accessControlPolicyIDs
attribute of Resource_1
Resource_
1
Resource_
2
Resource_
3
Set of ACPs associated
with Role 1
ACP_1
ACP_2
ACP_3
Role 2
...
ACP_4
...
...
Resource_
N
Role 1
ACP_M
Role K
• Any ACP may be part of
multiple Roles
• This model fits with the
current SRole-ID approach
(i.e. it allows assignment
of roles per resource type)
• It also enables
differentiation of roles for
instantiations of the same
resource type
Instances of
accessControlPolicy
resources (ACP)
© 2015 oneM2M Partners
SEC-2015-0640
9
Relation between Roles and ACPs
• If an AE-ID is associated with exactly one Role, any ACP which
includes that AE-ID in any of its access control rules inherits
that Role
• If an ACP applies to just a single Role, all AE-IDs used in there
must be associated with that same Role
• If the access control rules of an ACP includes AE-IDs
associated with different Roles, that ACP belongs to multiple
Roles (in the figure further above)
© 2015 oneM2M Partners
SEC-2015-0640
10
Proposal (2)
3.
Keep handling of Create request primitives as specified right now
– 1st step: registrar CSE checks if access to the requested resource type is allowed or not
for the Role associated with the originators AE-ID
– 2nd step: Hosting CSE applies regular Access Control mechanism
© 2015 oneM2M Partners
SEC-2015-0640
11
Proposal (3)
4.
Requests for operations other than Create can be forwarded to the
hosting CSE directly. For these operations, RBAC can be applied for each
individual resource instance just by assignment of the appropriate ACPs
– no change of the Release-1 access control mechanism is needed to cope with RBAC
– no need to add additional parameters to the ACRs (e.g. Role-IDs) to cope with Roles
– RBAC is implemented just by appropriate management ACPs including their assignment to
the resources
5.
All Request primitives should indicate the Role associated with the AE-ID
–
–
In registration requests the Role primitive parameter would indicate the requested RoleID
In other request messages explicit indication of the Role would help Hosting CSEs not
aware of the originator’s Role to check ACPs assigned to that role first, in order to
achieve access control decision more fast
© 2015 oneM2M Partners
SEC-2015-0640
12
ACP management
• ACP management requires awareness of and fast access to
the mapping illustrated in the figure on slide 9
– Without Roles probably two tables (dictionaries) are needed in an
implementation (since tables are not invertible), (Rsc = Resource)
• {“ACP_1” : [“Rsc1”, “Rsc2”, “Rsc3”], “ACP_2” : [“Rsc3”, “Rsc4”, “Rsc5”], …}
• {“Rsc1” : [“ACP_1”], “Rsc2” : [“ACP_1”], “Rsc3” : [“ACP_1”, ACP_2”], …}
• Note: #Resources >> #ACPs >> #Roles
– dictionary with resource (name) as key may become extremely large
– probably not an issue whether dictionary has many keys or many values for each key
– Introducing Roles implies two additional dictionaries:
• {“ACP_1” : [“Role_1”], “ACP_2”:[“Role_1”, “Role_2”], “ACP_3”:[“Role_K”], …}
• {“Role_1” : [ “ACP_1”, “ACP_2”, “ACP_4”], “Role_2” : [“ACP_2”, “ACP_4”], …}
– Tables with same key type may be combined, i.e. three dictionaries
required, one each for ACP, Resource and Role keys
© 2015 oneM2M Partners
SEC-2015-0640
13
Summary and discussion
• The proposed approach assumes that each AE-ID is associated
with a specific Role, which is assigned at AE registration
• With this approach, RBAC becomes primarily a matter of ACP
management
• Introducing Roles will likely result in a much larger number of
ACPs to be managed (for RBAC there will be likely many more
Roles to be differentiated than currently defined in Annex G of
TS-0001 as SRole-ID)
• The complexity of ACP management may become an issue.
This needs to be further investigated before concluding on the
RBAC solution.
© 2015 oneM2M Partners
SEC-2015-0640
14