Model for Subject Related Information Profiles and Identities

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 106 of 233

7.4. Access Control Information Model

In the following information model for the realisation of access control is presented with a reference to the corresponding OASIS standards.

7.4.1 Model for Subject Related Information

In the description of the SensorSA access control concepts in section 6.8.2 a Subject has been introduced as the requestor of a service operation who represents the acting entity, whereas an acting entity may be a user or a software component, e.g. a service instance. The profile and identity model defines the basic concepts related to a subject that support the tasks of the access control pattern introduced in section 6.8 and related services as described in section 8.3. The following elements of a subject-related information model are defined: - Profile - Identity - Group - Role - Policy

7.4.2 Profiles and Identities

A profile is the abstract representation of a subject, i.e., it is characterised by a set of attributes that describe a subject. The profile information comprises associated identities and may therefore serve as container of logical pointers to identities. The definition of a complete profile schema is out of the scope of the SensorSA information model for access control as it is application dependent. For instance, a profile attribute could be the social security number to be able to identify the real word user behind the subject, or it could contain the phone number to contact a responsible person or the signature of a software agent. The definition of profile attributes is a application design decision. In order to perform an authorised action e.g. a service request a subject represented by his profile has to provide a proof of authenticity so that a service provider can decide whether the requested action is in line with the service provider‟s access policy. A subject may present different identities, possibly authenticated with different authentication mechanisms, for different actions. Thus, a single profile may have multiple identities .By decoupling profiles from identities, on the one hand information not relevant for authorisation decisions can be kept away from the access control mechanisms, and on the other hand requirements like single sign-on SSO can be easily supported. The separation of profiles and their associated identities reflects the real life situation in which a single subject i.e. a single profile may have an arbitrary number of identities for particular purposes. A subject may authenticate one or more of its profile‟s identities and thus accumulate access rights in disparate security domains systems, networks and organisation. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 107 of 233 Profiles are managed created, deleted, etc. using an instance of the Profile Management Service see section 8.3.2. Profile attributes are used to store arbitrary profile related information e.g. first name, last name, address, e-mail. Identities are managed created, deleted, etc. using an instance of the Identity Management and Authentication Service see section 8.3.3 . Identity attributes are used to store information that can be the basis for an authorisation decision. The Identity Management and Authentication Service acts as an identity provider. The manner in which identity information is managed is up to the particular identity provider as different authentication mechanisms e.g. public keysecret infrastructures or loginpassword require different identity related information. In this way the task “profile management” see section 6.8.3.1 can act independently of the methods applied in the task “authentication” see section 6.8.3.3 and vice-versa. cd Profile and Identity Identity + active: boolean + id: integer + origin: string Profile + attributes: ProfileAttributesType + id: integer + origin: string 0.. 1 Figure 7-3: Profiles and Identities 7.4.3 Groups A group is modelled as a special type of identity that is composed of a set of identities. Group att ributes are used to hold common properties of its members‟ identities. An identity that is a member of a group automatically inherits all identity attributes of that group as after login all related group identities are included in the SAML assertion session information. Thus, groups facilitate administrative operations which need to be applied to a number of identities of a single Identity Management and Authentication Service instance. A group can be treated as an ordinary identity by an instance of the Policy Management and Authorisation Service see section 8.3.4. Therefore, writing policies for groups does not differ from writing policies for any other identity. Management of groups is done according to SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 108 of 233 the management of identities in instances of the Identity Management and Authentication Service see section 8.3.3. cd GroupIdentity IdentityType AttributedIdentity + attributes: IdentityAttributesType GroupIdentity + groupname: string Identity + active: boolean + id: integer + origin: string 1.. 0.. Figure 7-4: Groups are special Identities Groups can only be defined on the level of a single Identity Management and Authentication Service instance, since the concrete representation of identities, and thus groups, may vary from instance to instance. To allow cross domain Identity Management and Authentication, and thus cross security domain enforcement of access rights, the concept of roles is used.

7.4.4 Roles