The Security Assertion Markup Language 2.0 (SAML2) is an open standard and one of the key technologies for federated identity. It enables single sign-on (SSO), which is used to decouple authentication and authorization process from application. It means that a user can use a single credential to access multiple applications. User’s credentials are not stored in these applications, they are stored in trusted attribute authorities, which handle authentication and authorization processes by themselves. SAML2 is used to exchange these authentication and authorization data, called assertions. Assertions are in XML format. One assertion represents a set of information about an identity, made by SAML authority (e.g. SAML server). Assertions are exchanged between identity provider, an entity which is able to verify user’s credentials and service provider, an entity which needs identity provider to verify user’s credentials.

According to this request-reply model, there are 3 kinds of assertions: authentication assertion, attribute assertion and authorization assertion. Authentication assertion serves to assert, that the identity was authenticated by authentication mechanism at a certain time. Attribute assertion serves to assert, that the identity was associated with the specified attributes (name, surname, etc.). Authorization assertion contains a proof, that the identity has been authorized to access specific resource with specific rights.

Groups information can be carried by SAML2 in two ways:

1. Attributes: In this scenario, the group information is carried as SAML attributes as part of the Authentication statement. Many attributes in the commonly used eduPerson schema actually represent groups: 

a. eduPersonAffiliation provides a fixed naming scheme for labaling people into groups like student, faculty, member, etc

b. eduPersonEntitlement is used to express roles and rights and may represent groups of people.

c. eduMember IsMemberOf is commonly used to express group memeberships

In addition SAML allows arbitrary attributes to be used to express group membership.

Note that in this scenario the information is only available when a user logs in. This may therefor not serve all use-case.

2. SAML Attribute Query: This protocol provides a back channel for querying attribute- and thus also group- information from an SAML Attribute Authority.

Note that authorisation management between the SAML Attribute Authority and the requestion Services is based on the same mechanisms as between Identity Providers and Service Providers (SAML metadata). This mechanism is rather course, and may therefor not serve all use-cases.

Finally, it should be noted that SAML supports a variety of security mechanisms at transport- and message-level, namely SSL 3.0 or TLS 1.0 for transport-level security and XML Signature and XML Encryption for message-level security.

The MAGIC project stands for defining a Group Management in Federations (GMF) solution to foster sharing applications and resources in the community. The focus of GMF is in maintain group information in a central and secure location, and providing the capacity to share digital resources with other organizations or domains. For instance, the NRENs will be capable of handling the authorization based on group ownership. The NREN users could share resources with a complete group, access to specific functions or applications depending on their role,among others. Standards and technologies to handle GMF in a domain scope already exists, and there are initiatives of protocols to share this information like VOOT or Grouper, under the concept of virtual organizations. The MAGIC group will select a solution to be implemented in one application market, and establish a pilot with other one sharing group details in two applications. The first step towards this goal is to compare and evaluate the possible solution. This document presents the evaluation of the most advanced solutions in the area, and it will serve as the base ground to build requirements and advance to the committed pilot implementations.

Key functions and capabilities

The GMF importance can be revealed through the exposure of some use cases commonly seen in the collaboration environment. For the MAGIC group, the GMF should address cases like:

Authorization: An application in one service provider domain has a user connected to it. When the user wants to use an specific feature, the GMF should check if he belongs to an specific group or role, and allow or deny the access. All of this shall be done in a federated approach, and the user group information could be anywhere in its home institution.

Share information about groups: Some user applications could require or need to share its information to other domains. For instance, A specific group in Biology can benefit from having its existing public to the global community, and be able to use it in a remote application. This information can include: Global group type classification, Participants in the group, among others.

Single management interface (create and update group information): Nowadays, the organizations have to create groups and manage then in almost every application. The above leads to a highly edundant information, and complexity in its administration. A single domain shall have a single repository, and administration interface for its groups.

Federated management: Is the simplest and central capacity that GMF will fulfill. The groups information must be always up to date, and this requires management at the source. Every institution shall have the capacity to handle their groups information, and make it available to the entire community with the options to segment access or customize privacy features.

Assessment, evaluation and recommendation of global group and attribute management for inter-operation standardisation

MAGIC team evaluated the following standards and technologies for group management: VOOT, SCIM, Grouper, SAML2, OAUTH, OpenID, PERUN, SYMPA, OPENCONEXT, UNITY.

After the evaluation, it was concluded that OpenConext, PERUN, SYMPA, SCIM, and Unity could potentially fulfill the need to manage working groups.

Specifically, MAGIC identified the need for a Group Management solution that allows federated applications to provide authorized user access to certain resources based on group membership, as well as to share group membership information with applications in support of value-added collaboration features for groups.

Finally the definition taken is to work with VOOT, SAML2, PERUN and SYMPA.