Home » GN3 Identity Federations

GÉANT Identity Federations Work Plan Year 2

Submitted by Andreas Åkre Solberg [1] on 1 March, 2010 - 13:24

This is a work plan for GÉANT3 Identity Federations.

Table of Contents

1 Participants

Available resources include:

  • NorduNet Nordic 4.4 (15.8 MM)
    • UNINETT 3.3 (9.9 MM)
    • Wayf.dk 0.8 (2.4 MM) Pending...
    • NorduNet 0.3 (0.9 MM) OK.
    • SUNET (2.0 MM) Moonshot.
  • DFN Germany 3.6 (13.0 MM) Pending...
  • SURFnet Netherlands 3.0 (10.8 MM) Partly confirmed. Pending...
  • JANET UK (6.0 MM) OK. Moonshot.
  • Terena Netherlands 1.4 (5.0 MM) OK, confirmed.
  • CARNET/SRCE Croatia 1.2 (4.3 MM) OK. Awaiting confirmation.
  • RENATER France 0.8 (2.9 MM) Pending...
  • CESnet Chezch 0.4 (1.4 + 5.0 MM) Pending...
  • NIIF Hungary 0.4 (1.4 MM) Pending...
  • PIONIER Polen 0.4 (1.4 MM) OK, confirmed.
  • SWITCH Switzerland 0.4 (1.4 MM) OK, confirmed.
  • RedIRIS Spain 0.4 (1.4 MM + 3 MM) OK, confirmed.
  • RESTENA Luxembourg (0.6 MM) Moonshot?

Total of 16FTE. Approx 30% of this will be spent in year 2. The time scheduled for year 2 is listed in parenthesis (in number of Man Months).

Increased available resources allocated for the moonshot project is not yet included in the numbers above.
Some participants have somewhat more resources available due to under-allocation in year 1.

Full list of individuals participating in year 1

2 Work items year 2

2.1 Information Card (User-Centric Identity)

A full task description of this task needs to be sorted out by RedIRIS and PIONIER. Some initial ideas are shared below:

RedIRIS:

Our plan is to dedicate the work of this person to exploring LoAs in InfoCard, and explore how to propagate the LoA (from national ID cards, a SAML federation, etc). The idea would be to have an STS (and probably some sample RP) able to apply this. Furthermore, this potential grant would be tutored by Enrique de la Hoz who, as you know, has been working in exploring the connection of InfoCard and eduroam, so going further on this would be an additional path.

PIONIER:

There is one thing I miss in federation scenarios - I think that there is space for service providers which can essentially live with just targetedUserId. There are a lot of services like that and typically they are the first choice services for real user-centric id management. These services do not care if they know any real data about their users, they just need to make sure that if a user creates an account the this and only this user can log into it. It could be quite convenient for a user to use his federatied Id to access such services, but since these services do not want any real attributes form the IdP, I see no reason why such services should not be admitted without any hassle or paperwork. This is really a reverse approach to using self issued InfoCard, but I think that we could also put it into the User-Centric subtask.

Participants:

Progress: None so far, RedIRIS is looking for a new trainee to take over the work in this item.

2.2 Evaluation of data API alternatives for collecting Virtual Organization Data

This task investigates basic VO Data requirements and investigates the way this data can be exchanged between VO and Services

Participants:

OpenSocial may be preferred over alternative less mature front-channel approach.

As of now; we have at least two good candidates to move forward with: OpenSocial + SAML 2.0 AttributeQueries.

2.3 CLARIN End-User Licence Agreement Attribute Authority Proof of Concept (Virtual Organizations)

The CLARIN project is a large-scale pan-European collaborative effort to create, coordinate and make language resources and technology available and readily usable. CLARIN offers scholars the tools to allow computer-aided language processing, addressing one or more of the multiple roles language plays (i.e. carrier of cultural content and knowledge, instrument of communication, component of identity and object of study) in the Humanities and Social Sciences.

Many of the resources available in the CLARIN language resource domain will not be accessible without adhering to some legal and/or ethical rules that are typically expressed in license statements that have juridical implications and in Code of Conducts. While license statements are very well known, CoCs need some explanation. A code of conduct (CoC) defines a set of rules of proper usage and proper ethical behavior that is required before a user is allowed access to a resource, i.e. a user commits him/her-self to adhering to this rules and the community will take control behavior. We refer to all these as EULAs (End User License Agreements).

Identity Federation has been in meetings with the CLARIN project discussing how technology from this task can be applied to this use-case. After evaluating various technologies, Identity Federations in agreement with CLARIN project participants, have concluded that a solution based upon SAML 2.0 Attribute Queries and Shibboleth software, they may effectively solve their use case.

In the proposed solution, a central EULA server will implement a user interface for collecting EULA agreements from users, and this server will also act as an Attribute Authority running Shibboleth 2.0 IdP. All CLARIN Service Providers may be configured to collect EULA information about the current user during the login process.

The CLARIN project is planning to implement a proof of concept of this design with guidance from Identity Federations during 2010.

Participants:

Progress: Waiting for any questions the clarin guys might have. From our point of view they could start using it after slight modifications to meet their special needs.

Update: The financing of the project runs out this year, should they be able to get a refinancing they will deploy our technology, but apparently earliest at the end of this year.

29th June e-mail from Mikael Linden: Four SPs connected to Haka

2.4 Implement AttributeQuery Protocol in SimpleSAMLphp compatible with Shib IdP Attribute Authority (Virtual Organizations)

Participants:

Work probably has not started.

2.5 Shibboleth AttributeAuthority with AffiliationDescriptor (Virtual Organizations)

In year 1, a proof-of-concept Virtual Organization Platform using the SWITCH Group Management Tool (GMT) was implemented. It used the values of the eduPersonPrincipalName, email or swissEduPersonUniqueID attribute as shared user identifier (Shared ID) to aggregate user attributes from multiple sources (user's home Identity Provider and the VO Platform). The values of these attributes are the same for a particular user and all services that are accessed by this user. Therefore, the use of these attributes in an environment where a user can be a member of multiple Virtual Organizations (VOs) involves risks when it comes to data protection.

A better choice to use as Shared ID would be using a targeted, random and persistent identifier, similar to the value of the eduPersonTargetedID. Shibboleth 2.x supports the usage of a persistentID as name identifier. The values of this persistentID can be generated in the same way as the eduPersonTargetedID. Using a the persistentID as Shared ID would alleviate the data protection issues in the context of a VO. However, to be used as Shared ID, it is necessary that the persistentID is the same for a specific user when this user accessses the VO Platform as well as all services belonging to a particular VO. Therefore, it is necessary that the value of the persistentID is the same for all components in the same VO but different for other services.

In order to achieve that the persistentID name identifier is the same for a user and all services of a particular VO, it is necessary to use SAML 2 Metadata AffiliationDescriptor elements. These elmenets in SAML 2 metadata contain a list of all entities for whom the same persistent name identifier is generated.

The goal of this task is to gain experiences when it comes to use the AffiliationDescriptor for usage in the context of VOs. In particular, the VO proof-of-concept using the GMT should be extended to use the persistentID name identifier as Shared ID. The inter-federation tests performed in year 1 using the GMT proof-of-concept shall be repeated if possible.

There is a dependency on this task because the Shibboleth Identity Provider needs to support the AffiliationDescriptor first. It is expected that there will be a new Shibboleth Identity Provider release in March or April 2010. This release is very likely to contain the new AffiliationDescriptor feature.

Participants:

Progress:

The Virtual Organization demo using Shibboleth with SAML 2.0 Attribute Query for exchanging data is taken to the next step. SWITCH has started testing with a pre-release of Shibboleth IdP 2.2, the AffiliationDescriptor functionality that will improve privacy in the VO data exchange over the demo shown in Year 1 of the project. The firsts tests indicate that this works as expected with the software, and no big issues was found. Work will be continued.

2.6 Write a SimpleSAMLphp authenticaiton processing filter supporting the OAuth VO Architecture (Virtual Organizations)

This work needs to be done in order to support Authorisation on Terena Wikis (Virtual Organizations).

Participants:

Work on OAuth VO Architecture will be replaced by OpenSocial. Writing an authentication processing filter for simpleSAMLphp supporting OpenSocial seems reasonable.

2.7 Continue the work on the draft OAuth attribute retrieval protocol (Virtual Organizations)

This item may be discarded in favour of OpenSocial which kind of is a well-defined protocol more or less doing the same as the proposed OAuth attribute retrieval protocol.

Participants:

Work on OAuth VO Architecture will be replaced by OpenSocial. This task item is cancelled.

2.8 Authorisation on Terena Wikis (Virtual Organizations)

Terena is providing a wiki for collaboration between European NRENs in various areas. Users that should have access to the wiki are spanning multiple identity federations and hence the need for Virtual Organizations for authorization and access control is obvious.

Until now, the wiki has required participating institutions to set a special entitlement flag in the LDAP user repository for those that should have access to the wiki. This is not an optimal solution and has been criticized as there is not a defined policy for who is allowed to set flag for themselves or others. Some users may not access the wiki with today's practice because their institution does not have any procedures for setting entitilement values.

As the Terena wiki uses SimpleSAMLphp for access control, it is an obvious use case for the new Virtual Organization modules implemented for SimpleSAMLphp as described in the section about VOs above.

Participants:

What about using OpenSocial + SurfGroupen for that?

Miro: Experimenting with SimpleSAMLphp VO + Oauth.

Other servies as well...

Make a dedicated VC on this.

2.9 OpenSocial (Virtual Organizations)

Introduction

The OpenSocial API (http://www.opensocial.org) is a young, yet well established standard within the world of Social Networking. It is rapidly gaining acceptence beyond the domain as well, see for examle the 'Enterprise OpenSocial Whitepaper' (http://www.opensocial.org/page/enterprise-opensocial). The API basically offers two APIs. One, the 'Gadget' API deals with the rendering of functional enduser GUI components. The other, the 'Social Data' API provides an API for people, groups, notifications and activities. OpenSocial describes two interfaces for both API's. A RPC based API is mostly geared towards GUI and Gadgets functionality, while a REST-based API is available for exchanging attribute data in a RESTfull meanner. oAuth is the standard mechanisme for secure exchange of attribute data in that scenario. Both API's offer roughly the same functionality.

OpenSocial Data Container

The basic idea is to implement a so called OpenSocial Data Server, based on the Open Source Shindig, (http://shindig.apache.org/) inside the VO platform. Such a data server is actually very dumb and can only do one thing: serve data from "a backend system" via the OpenSocial API to 'clients'. In our case, the backend system would be Identity Federation(s), their saml attributes and the VO group manager and attribute aggregator data. Figure 1 presents a schematic overview of the proposed setup. The 'client', or in our case the Vo services, can be anything. However, these now only need to implement a standards based API solution for consuming and exchanging person and group attribute data, in stead of a nonstandard SAML attribute consumption.

Attribute mapping

The OpenSocial API already has a number of attributes for users and groups that can be mapped directly to common federation attributes, see http://opensocial-resources.googlecode.com/svn/spec/draft/Social-API-Server.xml for the 1.0 version. For a number of other attributes that we would like in the edu space (studentnumber, digital author id, t.b.d.), we propose to extend OpenSocial with 'eduSocial'. The OpenSocial is already geared towards extending the standard, so doing this can be accomplished without breaking things.

Clients

One of the problems with SAML based attribute assertions is that these are primarily focused on persons. An attribute is always in some way a propertiy of a person. This relates poorly to the need to exchange other data between VO and Service, like e.g. group related data, or notifications. Also attribute assertions will most like not scale very well if the amount of content in the assartion becomes larger. Therefor a mechanism that can be provided with a fairly limited set of person attributes in the SAML assertion (only a person identifier?), and then use that attribute to query additional data from the VO seems better suited. The OpenSocial Social Data API can be just that API. Several client libraries currently exist for consuming the OpenSocial API. Supported languages include: PHP, Java (including Android support), .NET, Ruby, Python, Objective-C (including iPhone support), ActionScript (ActionScript Library that calls the naitive JavaScript OpenSocial API) Given this large set of available clients and supported platforms, very little applications cannot (be made) deal with this.

Goal

The goal of this task is to gain experience with exchanging of attributes between VO and Services based on the REST-based OpenSocial API. Also Furthermore, this task will identify attributes from standard attribute schemes to be included in the eduSocial extention.

Participants:

Progress: Marten Kremers gave a presentation in Utrecht on the 11.5.2010, slides are available on the geant meeting site.

Niels: make a note, send to the list. And invite to a new meeting.

2.10 Define Front-Channel Attribute Query Profile for SAML 2.0 (Virtual Organization)

Defining a new SAML 2.0 Front-channel Attribute Query Profile.

Participants:

Progress: Thorough discussions have taken place regarding the use of SAML2 front channel methods for attribute aggregation. To our surprise, no consensus has been reached. A report describing the different viewpoints will be produced. WAYF has subsequently developed a prototype attribtue collector (Springfika), based on WAYF's interpretation of the SAML2 specification (which by the way explains why no 'Front-Channel Attribute Query Profile' exists already: it is mutually exclusive with the SAML2 core specification.

David: Report under way - con's and pro'sCorto (attribute aggregator) build based on discussions and enhanced understanding of SAML2 spec.

Website:

Andreas: move to a separate work item...

2.11 Best practice on De-Provisioning (Federation Harmonization)

Write a best-practice document, covering the following topics:

  • The semantics of deprovisioning
    • What it means to deprovision an identity
    • The differences between deprovisioning and PKI revocation
  • Applicability
    • Important uses of deprovisioning
  • Push vs pull
    • Deprovisioning in the enterprise
  • Deprovisioning as attribute aggregation
    • Using SP-centric attribute aggregation
  • Privacy aspects
    • Problems with the SP-centric approach
  • Other alternatives
    • RSS, ATOM, OCSP, etc

Participants:

Niels and Lukas participants?

Leif invited to meeting? Status...

2.12 Continue work on saml2int (Federation Harmonization)

Continue the work on the Interoperable SAML 2.0 Web Browser SSO Deployment Profile available at http://saml2int.org.

Participants:

Progress: WAYF has taken part in the development of the saml2int-profile since the beginning, proofreading and discussing the various elements of the profile (ie. exclusion/support for authentication request scoping elements) as well as the support structure for the profile (maintenance procedures, standardization etc.).

SAML2int v0.2 was made up from scratch, merging SAML2int v0.1 with Internet2 requirements, as well as incorporating comments from the community.

  • Mikael Linden: Prepared a comparison of e-Gov and saml2int.
  • Kantara: Federation Interoperability Working group: US e-gov. Jacob Steen.

2.13 Interoperable SAML 2.0 Logout Profile (Federation Harmonization)

Participants:

Progress: Summarize the presumptions needed to safely deploy Single Logout wihtin an organization or federation and extend the current document with these requirements. Next revision of the document is due in August 2010.

2.14 Federation Lab version 1.0 (Federation Lab)

The idea behind the Federation Lab is that when cross-federations like eduGAIN are operational and SAML 2.0 Deployment Profiles like saml2int are being used, there is a need for some tools to validate whether a SAML entity conforms to the usage pattern of SAML that the cross-federation agrees upon.

Features to be included in the federation lab:

  • Ability to test an SP against an IdP in the Federation Lab
  • Ability to test an IdP against an SP in the Federation Lab
  • The Federation Lab will report any misbehaviour of the entity that is beeing tested.
  • The Federation Lab will test whether the entity beeing tested meet the specification of the SAML 2.0 profiles reccomended for inter-federation communication.

Participants:

UNINETT has just started on a SAML 2.0 Service Provider Validation tool to be part of the Federation Lab. Screencasts are available on the web for an demonstration of how it works.

2.15 Metadata trust management and Dynamic SAML Draft (Metadata distribution)

  • Dynamic SAML
  • Another idea of using TACAR for trust.

Participants:

Milan: Metadata aggregator, publisher.. re-tagging.

2.16 Discovery Service supporting Geo-Location (Metadata distribution)

SWITCH recently published a draft IdP Discovery and Login UI Metadata Extension Profile including definition on how to store information about geographic position of a SAML entity (GeolocationHint).

Use this new draft with SAML 2.0 Metadata, and implement a proof of concept that makes use of this information together with the HTML 5.0 Geo-location API.

Implementation should build upon an existing Discovery Service, such as the discopower module in simpleSAMLphp, or another existing implementation.

Participants:

Progress: WAYF has made preliminary investigations into how to take advantage of geo-information in discovery services. Map-based solutions already exist (RedIRIS, Kalmar Union), but more advanced features like zooming, context aware mapping etc. will be investigated further. This is seen primarily as a usability study. Everyone is invited to join the task.

Preliminary work, workshop on fraunhof institute: rebuilded a new discovery service. Usability study. will be circulated on the list.

Wayf has implemented and designed a new discovery service with enhanced user experience. Work will be continued including support for the Geo-Location API of HTML5.

2.17 Metadata aggregator specification (Metadata distribution)

Complete the draft that is work in progress; available here:

Outcome of this work item should be provided and evaulated for adoption in GÉANT eduGAIN.

Participants:

Andreas may provide input.

Sidenote: Shib Metadata aggregation: Chad has started working for UK. Passed first milestone. Running code by November.

  • Shad REST API IETF-draft.
  • More collaboration between SA edugain and JRA IdFed.

Lukas schedules new meeting.

2.18 SimpleSAMLphp Metadata Engine, Aggregator and Consumer (Metadata distribution)

This task includes re-writing the metadata engine in simpleSAMLphp to better be able to represent all the available elements from the SAML 2.0 Metadata schema, and full support for entity attributes.

  • Create a new metadata engine
  • Make use of that metadata engine in SimpleSAMLphp as a Metadata Consumer; metadata in simpleSAMLphp will then be more oriented towards the XML schema than on the internal format.
  • Make a new metadata aggregator based upon the new metadate engine.

The support for entity attributes, would include the following:

  • Consumer would be able to configure authentication processing filters for a group, based upon entity attributes, not only configuration per entity.
  • Aggregator would support filtering based upon entity attributes

Participants:

Progress: The metadata engine is mostly complete - it can parse and generate XML metadata, including entity attributes. The classes for converting between the internal metadata format and the XML metadata format has been switched over to using this metadata engine.

A metadata aggregator has been implemented on top if this engine, but is not yet capable of filtering on entity attributes. Configuration of authentication processing filters based on entity attributes is not yet implemented.

2.19 Moonshot (Beyond WebSSO)

Josh H. work item.

Participants:

  • Josh Howlet, JANET, Josh.Howlett@ja.net
      • 0.25 FTE - management & specifications
  • Simon Wilkinson (U of Edinburgh) (probably won't happen)
    • 1 MM
  • Dubravko Voncina, CARNET/SRCE, dubravko.voncina@srce.hr
  • Miroslav Milinovic, CARNET/SRCE, miro@srce.hr
    • 2 MM - integration testing and test-bed (March-April 2011)
  • Stefan Winter, Restena, stefan.winter@restena.lu
    • 0.6 MM - specification review
  • Linus Nordberg, NORDUNET
    • 2MM - implementing libradsec (july - october 2010)
  • Daniel Kouril, University of Masaryk
  • Michal Prochazka, University of Masaryk
    • 0.5 FTE - implementing mod_auth_gss & moonshoot libcurl

Progress: Josh gave a presentation in Utrecht on the 11.5.2010, slides are available on the geant meeting site.

The Fedauth BoF has been approved by the IESG for IETF 78 in Maastricht at 0900 on Tuesday 27 July. This will be co-chaired by Leif Johannson and Sam Hartman. We have proposed a WG charter, which will be the focus of discussion at the BoF. The mailing list has nearly 100 subscribers.

If the Working Group is approved, we intend to have an interim WG meeting on Monday 20 September at NORDUnet in Copenhagen.

This will be followed by a Project Moonshot Kick-Off Meeting on Tuesday 21 September.

Implementation work has just started. This is a summary of the work currently being performed by GN3 participants.

  • Linus Nordberg of NORDUnet is implementing libradsec, which will be based on radsecproxy; this is an important dependency of the GSS library that 'moonshooted' applications will use.
  • Daniel Kouril of the University of Masaryk is implementing a new Apache module, based on mod_auth_kerb, that will provide a GSS layer for Apache; this is an important dependency of the Shibboleth SP work.
  • Stefan Winter has performed some review of our AAA-related specifications.

We are otherwise very busy negotiating contracts with the non-GN3 contributors.

There is a detailed project plan on the Project website (http://www.project-moonshot.org). We have identified developers for all of the main software components. However, we would like to see an implementation in simpleSAMLphp (we are presently only targeting the Shibboleth IdP and SP); if anyone is interested in this, please let me know...

2.20 SimpleSAMLphp OAuth Client Authentication (Beyond WebSSO)

In Year 1 a proof of concept of OAuth client authentication was implemented in SimpleSAMLphp. This PoC needs to be improved some and include better support for including a authorization of client step, where the user accepts that a client is talking with the provider on behalf of the user.

Participants:

3 Description of Work Areas

3.1 User-centric Identity

Last years within the Identity field, user-centric identity has gained alot of attension. There are at least two significant user-centric technologies that is worth exploring in the context of educational federations, including:

  • OpenID
  • InformationCard

OpenID is already considered and tested within educational federations, and some even support it in production. InfomationCard is a far less explored area, but many thinks it will play a really big role in the future.

In the first year of Identity Federations the focus will be on investigating this new technologies, and understand how to make use of them in educational federations.

3.2 Federation Lab

Running a federation involves providing a test environment including SP and IdP facilities that SPs and IdPs can use in order to test their deployments without connecting to the live production environments. As most european federation supports the SAML 2.0 standards, european federations most likely run very similar test facilities. This task involves looking into creating a common European test facility. With joint effort we can improve the functionality of such a test facility beyond what is available today. We call this common federation test facility the “Federation Lab”.

3.3 Virtual Organizations

When SSO across national borders, the next functionality that is needed in order to better collaborate online is the ability to create groups of people and use those groups to define access control.

This project intends to create a privacy-preserving VO solution that works in an inter-federation context. A proof of concept service should be created, ready to be deployed in eduGAIN (SA3).

Some of the problems with existing VO solutions is:

  • No standardized protocol for looking up groups or memberships.
  • Privacy-invasive protocol used for looking up groups or memberships.
  • Dependancy on an Identity Provider makes it almost impossible to deploy in an inter-federation context.
  • We should aim to solve all these problems in a new solution.

3.4 Metadata distribution

Manually exchanged metadata does not scale on a cross-national level. An infrastructure for automatically exchanging metadata with a supplied trust-model is neccessary. This is a less in explored area as of now. More experience is needed in the area.

This item includes investigation in multiple alternative approaches to metadata distribution.

Internet2 has come up with a completely distributed metadata distribution method, referred to as Dynamic SAML. The lack of a supplying trust model to this method, has prevented it from been investigated more. This method has potential and should be investigated more in the context of European federations.

Two other models that should be investigated is the simple pull-model used in the nordic Kalmar Union, and flavours of the metadata service implemented as a part of GEANT2.

Tasks:

  • Investigation on accompaning trust-models for Dynamic SAML for automated metadata distribution.
  • Investigation on Kalmar model

3.5 Beyond Web-SSO

Most european federations have authentication solutions focused on WebSSO only, and there is a high demand for re-using the authentication framework for other architectures, like non-web-based applications and command line utilities.

In this work item track, participants will investigate in existing solutions, and new ideas.

3.6 Federation Harmonization

This project involves some independent topics that should be studied in an inter-federation context. Each of these topics should result in a short best practice document.

Managing a federated identity infrastructure involves a lot of choices. Best practice documents may guide federations to make the same choices, and hence increase tha chances for cross-federation interoperability.