1. Context-based Access Control
4/27/2017
Context-based Access Control
A. Corradi, R. Montanari & D. Tibaldi, “Context-Based Access Control Management in Ubiquitous Environments”, Network Computing and Applications, Third IEEE International Symposium on (NCA'04), August 30 - September 01, 2004, Boston, MA.
This presentation will be our review of a paper by Antonio Corradi et. al. titled “Context-Based Access Control Management in Ubiquitous Environments”, and I will also present some of our contributions towards a CBAC generalized architecture that will used in my dissertation titled “LOCATION-BASED ACCESS CONTROL MODELS : A GENERALIZED ARCHITECTURE”
A review by A. Escobar & Dr. Maria Petrie
Department of Computer Science
Florida Atlantic University
March 31st , 2005

2. Context-based Access Control
4/27/2017
Traditional RBAC not applicable.
Service providers do NOT know in advance the identities/roles of all subjects.
Users could be unknown entities.
Traditional RBAC model is not applicable to ubiquitous services. The design and deployment of ubiquitous services lead to serious security risks and access control problems. Traditional security solutions like the RBAC model seen in the figure, typically evaluate permissions depending on the identity/role of the client requesting access to resources. In this traditional RBAC model the role provides a level of indirection between subjects and their rights. However in ubiquitous services sometimes the service providers do NOT know in advance the identities or roles of all the subjects seeking access and sometimes service providers deliver services often to unknown entities.
- RBAC model taken from [Fer04]

3. Context-based Access Control
4/27/2017
Context-based AC (CBAC).
As with role, context provides a level of indirection between users and permissions.
Now, inspired by the management flexibility of the RBAC model, just as role, context can provide a level of indirection between users (Subjects) and permissions (Rights) . So Instead of managing users and their permissions individually, a system administrator defines for each context the set of applicable permissions. When a user operates under a specific context, s/he immediately acquires the set of permissions active for the related context. When s/he changes the operating context, the previous permissions are automatically revoked and the new permissions acquired.

4. Security Framework: Corradi’s Contribution:
4/27/2017
Corradi’s Contribution:
Allows flexible solutions for CBAC.
Defines 3 views:
Desired View : Resources that a user is willing to access.
Allowed View : Accessible Resources depending on context-dependent AC Policies.
Active-Context View : Desired View ∩ Allowed View.
Supports Privacy of user context information.
Active-Context View
Desired View
Resource Allowed View
Sys. Allowed View
Corradi’s security framework focuses on three main aspects: one is to allow flexible solutions for CBAC and this is done by allowing the AC decisions depend on dynamic context attributes, such as resource state and availability, in addition to more traditional attributes, e.g.,
the identity or role of the user. Second aspect he focuses on in his security framework is the ability to create an active context view for the users so they may have visibility over directly accessible physical and/or logical resources. This view is calculated out as the intersection of the Desired view and the Allowed view. The Desired View include resources that a user is willing to access, the Allowed View include accessible resources depending on context-dependent AC Policies. And finally the third aspect he focuses on in his security framework, is privacy support in the propagation of user context information, by allowing users to specify their own AC policies which taken into consideration when calculating the allowed view. Our contribution presented here are the 3 different Venn diagrams depicting the possible calculation of the Active-Context view.
Sys. Allowed View
Desired View
Allowed View
Active-Context View
Active-Context View
Desired View
Resource Allowed View

5. Context Model Corradi’s Contribution: Physical Context:
4/27/2017
Corradi’s Contribution:
Physical Context:
Identify physical spaces.
There is only one per user.
Holds references to the protected resources.
Logical Context:
Identify logical states of users and resources.
Many per user/resource.
Corradi’s access control management distinguishes two different kinds of context: physical and logical. Physical contexts identify physical spaces, delimited by specific geographical coordinates. At any time, one user can be associated with only one physical context and this is for obvious reasons, since a user cannot be in two places at the same time. Each physical context holds references to the resources to be protected. Logical contexts identify logical states of users and resources. At any time, entities may be associated with many different logical contexts. For instance identities and roles are considered as specific types of logical contexts. This way subject-based access control can also be handled if needed.
Not UML and taken From [Cor04]

6. Context Model Our Contribution:
4/27/2017
Our Contribution:
UML representation of Corradi’s Context Model. in
User * *
Logical_Context
Location_Context
{User may only be
in 1 Location_Context
at a time}
Our contribution is the UML representation of Corradi’s Context Model. Physical context has been renamed as Location context.

7. Physical Context Corradi’s Framework for Physical Context:
4/27/2017
Corradi’s Framework for Physical Context:
Our UML interpretation:
Now let’s take a much closer look at the Physical context. It has a Name that uniquely identifies the context, a Type qualifying the context type, and a set of Activation Conditions that represent the physical conditions that determine the activation of the context. For instance, the Cinema context example shown in the picture, represents a physical area delimited by the geographical coordinates defined in the activation conditions.
Context
name:
type: {Physical | Logical} activation_cond.:Set of Predicates
activate( );
deactivate ( );
Physical_Context
name = “Cinema”
type = Physical
activation_cond=GeoCoordinate.IsEqual(Area.GetInfo)
activate( );
deactivate ( );

8. Logical Context Corradi’s Framework for Logical Context:
4/27/2017
Corradi’s Framework for Logical Context:
Our UML interpretation:
The Logical context has a Name that uniquely identifies the context, a Type qualifying the context type, and a set of Activation Conditions that represent the logical conditions that determine the activation of the context. For instance the Tourist context shown in the picture, represents a logical context modeling the Tourist user role within the environment. In particular, this logical context is active for users who have visited the monitored location less than a threshold number of times (N).
Logical_Context
name: “Tourist”
type: Logical activation_cond.:MonitoringSystem.GetVisitNumber.IsLess(N)
activate( );
deactivate ( );

9. Resource Corradi’s Framework for Resource: Our UML interpretation:
4/27/2017
Corradi’s Framework for Resource:
Our UML interpretation:
Now let’s take a closer look at a resource. It has a Name that uniquely identifies the resource and a Description that reports the resource properties. In the example shown in the picture, the resource representing a Spiderman Movie has some properties given via a local resource manager. The resource description contains information about resource type, resource owner and resource usage.
Resource
name:
description:

10. Context Model Our Contribution:
4/27/2017
Our Contribution:
UML representation of Corradi’s Context Model.
Context
name:
type: activation_cond.:
protects
Resource
description:
User
Logical_Context
Location_Context *
Our contribution is the UML representation of Corradi’s Context Model.

11. Security Model Corradi’s Contribution :
4/27/2017
Corradi’s Contribution :
Allow System Administrators and Users specify their own policies.
Introduces Metadata:
User/Device/Resource Profiles (Security logic).
Access Control Policies (Security control).
Allowing separation between security logic and security control.
Corradi’s Security Model allows system administrators and final users to specify their security requirements at a high level of abstraction in terms of metadata. Metadata are declarative rules that describe both user/device/resource profiles and AC policies. Metadata permits to separate security logic from security control facilitating this way an automated security reasoning. System access control policies are the ones specified by the system administrators and security waves are the ones specified by the users to protect their privacy.
Not UML and taken From [Cor04]

12. Profiles User Profile Device Profile : Don’t know the substructure.
4/27/2017
User Profile
Properties
Desired View
Desired Objects.
Desired Actions to be performed on Desired Objects.
Context Conditions to perform the Desired Actions.
Device Profile : Don’t know the substructure.
Resource Profile: Don’t know the substructure.
User_Profile
properties
desired_view
Let’s take a closer look at the Profiles. There are 3 types of profiles: User, Device and Resource profiles. User profiles for instance has two sub-structures: user properties and desired view. User properties specify relevant user characteristics such as user physical characteristics like location and user logical properties like name or role and so on. Desired view expresses the user preferences for the resources s/he would like to find and the desired actions on that visible resource. The sub-structures for the Device profile and the Resource profile are not mentioned in his paper.

13. A User Profile User_Profile properties desired_view 4/27/2017
This is an example of a user profile. User properties are not shown in detail, but the desired view is. In this profile the user is willing to know if there are any vacant seats for the Spiderman movie in any cinemas within 3 Km of his location. This desired view is composed by the set of desired objects, for instance “nearby cinemas” and “Spiderman moview” under the objects tag, also the set of actions that the user would like to perform on these objects, for instance “find vacant seats” under the actions tag, and the context conditions in which the user desires to perform the specified actions, for instance “within 3 Km” under the active_context tag.

14. Profiles Our Contribution: UML representation of Corradi’s Profile.
4/27/2017
Our Contribution:
UML representation of Corradi’s Profile.
Profile *
Property
Desired_View
Objects
Actions
Context_Cond. 1
Resource_Profile
Device_Profile
User_Profile
Our contribution is the UML representation of Corradi’s profile, assuming that the Device and Resource profiles would have the same sub-structure as the User profile.

15. Security Model Our Contribution:
4/27/2017
Our Contribution:
UML representation of Corradi’s Security Model.
Profile *
Property
Desired_View
Objects
Actions
Context_Cond. 1
Resource_Profile
Device_Profile
User_Profile 1 *
Context
name:
type: activation_cond.:
protects
Resource
description:
User
Logical_Context
Location_Context *
Devi ce
Our contribution is the UML representation of Corradi’s Security Model.

16. Access Control Policies
4/27/2017
Association rules between set of permissions and set of contexts.
Simple Association ( One permission to One Context)
And, Or & Dependence Associations (One permission to many Contexts)
System Level.
Administrator defines permissions.
Protect system resources
User Level.
User defines permissions.
Protect user privacy.
Corradi’s access control policies are defined as association rules between a set of permissions and a set of contexts. Thus, policy specification requires not only to define permissions, but also to associate them with the contexts in which they should apply. Corradi associates permissions either to individual contexts (simple association) or to multiple contexts composed according to and, or, and dependence relationship (and, or, dependence association). Access control policies rule context-based access control and determine the user allowed view. There are two type of AC Policies, the system level and the user level ones. System level AC policies are specified to protect system resources from illegitimate use by incoming mobile users. Through system access control policies, security administrators define which permissions are activated on target resources by the specified context conditions. User level AC policies (Security waves) are used to reduce user privacy violations. Through security waves, users specify which personal information can be propagated to other users in specific context situations.

17. Permission Corradi’s Permission: Our UML interpretation:
4/27/2017
Corradi’s Permission:
Our UML interpretation:
A permission includes a Name that identifies the permission, an Action that specifies an allowed operation, a Target representing the resource the specified action can apply on and a Kind representing the positive or negative meaning of the permission. In the Figure we see an example of permission (P1) that allows to see “Horror Movies”. For those who are familiar with the (S,O,T,P) permission tuple, the object (O) is the resource, the access type (T) is the action, the predicate (p) is embedded in the associated context and the subject (S) is the one within the active context.
Permission
name:
action:
kind:
Resource
description:
target
< s, o, t, p > o t

18. Context-Based Access Control Policies
4/27/2017
Context
Permission
name:
action:
kind:
Resource
description:
target 1
1..*
CBAC Policy
assoc_type:{Simple|Or|And|Dependence}
allowed_view()
System_Policy
User_policy
CBAC policies are defined as association rules between a set of permissions and a set of contexts. In the figure we can see four different policies. The first one associates the “Adult” context with the permission “P1”, in a simple type association. Let’s remember the permission “P1” stands for the right to see an horror movie. Therefore this policy states that only adults have the right to see an horror movie. In the figure you can see our UML interpretation of a CBAC policy.

19. Profile Property Desired_View Resource_Profile Device_Profile
4/27/2017
Profile *
Property
Desired_View
Objects
Actions
Context_Cond. 1
Resource_Profile
Device_Profile
User_Profile * * 1 *
Context
name:
type: activation_cond.:
protects
User
Logical_Context
Location_Context *
Device
Context
Permission
name:
action:
kind:
Resource
description:
target 1
1..*
CBAC Policy
assoc_type:{Simple|Or|And|Dependence}
allowed_view()
System_Policy
User_policy
And this is what the whole model look like.

20. MBAC Pattern MBAC pattern taken from [Fer04] 4/27/2017
Pattern name: MBAC Pattern
Intent: Control access based on properties of subjects or objects.
Context: Any environment where we need to control access to computing resources and where some users may not be pre-registered.
Problem: Similarly to the other patterns in section 4, permissions for subjects accessing security objects have to be described in a suitable way. The administration of authorizations should be simplified as done in Role-based Access Control. In addition, in open systems such as web portals we usually don’t know the subjects in advance. Access may also be dependent on property values of the object
Solution: Subjects in requests and actual requested objects are represented as sets of attribute or property values. In addition, we need to represent authorization subjects and objects as sets of predicates or assertions on attribute or property values, i.e. the authorizations are not defined directly between subjects and objects but between so called subject and object descriptors. A subject descriptor consists of several attribute conditions (e.g. age > 21, ZIP code beginning with “93”) which can possibly correspond to several real subjects. The same holds for the object descriptors, where conditions are defined on object properties (e.g. related to a certain project, released by a certain publisher). As a consequence, subject and object descriptors are something like subject and object groups, however, not explicitly grouped by an administrator, but implicitly by their attribute or property values.
MBAC pattern taken from [Fer04]

21. MBAC Pattern Not mapped yet Device Device Profile
4/27/2017
Not mapped yet
Device
Device Profile
CBAC Policy
1..*
protects
<<user>>
1..*
<<resource>>
Context
Subject
Object
physical
target * 1 *
AttributeValue
PropertyValue
<<permission>>
Right
accessType
value
value * * 1 1
<<property>>
<<user_profile >>
<<resource_profile >>
<<property>> * *
Attribute
Subject
Descriptor
isAuthorized
Object
Property
Descriptor
This is the correlation between the MBAC pattern and the CBAC model.
For 1 1 * *
<<desired_view >>
<<desired_view >>
Attribute
Qualifier
Property
Qualifier * *
operator
operator
value
value
MBAC pattern taken from [Fer04]

22. References
[Boo98] G. Booch, J. Rumbaugh, I. Jacobson “The Unified Modeling Language User Guide”, Addison-Wesley Pub Co; 1st edition (September 30, 1998).
[Cor04] A. Corradi, R. Montanari, D. Tibaldi, “Context-Based Access Control Management in Ubiquitous Environments”, Network Computing and Applications, Third IEEE International Symposium on (NCA'04), August 30 - September 01, 2004, Boston, MA.
[DeC03] S. DeCapitani di Vimercati, S. Paraboschi, P. Samarati “Access control: principles and solutions”, ACM Software—Practice & Experience, John Wiley & Sons, 33 (5): , April 2003.
[Fer04] T. Priebe, E.B.Fernandez, J.I.Mehlau, and G. Pernul, “A Pattern System for Access Control” Procs. of  the 18th. Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Sitges, Spain, July 2004,
[San96] R. Sandhu, E. Coyne, H. Feinstein, C. Youman "Role-Based Access Control models", IEEE Computer , 29(2):38-47, February 1996.
[San94] R. Sandhu, P. Samarati, “Access Control: Principles and Practice”, IEEE Communications Magazine (1994, 40-48).