Identity Federations Status Report – January 2012

GÉANT Identity Federations currently have a lot of ongoing activities. Here is a summary of what we are working on, and the current status.

Federation Lab › Test Federation

Goal:

allow new SPs and IdPs to easily connect to a set of available entities that are available with no contract neccessary. Self-maintained.

Activity expected to be done April 2012.

Miro: Nothing to update.

Federation Lab › Monitoring and statistics

Miro: As I promised we’ve done preparations for using f-ticks with SSP in production in our federation. I’ll be able to report on that next month.

Federation Lab › SAMLtracer

A significant patch reveiced from Mark Dubrovnic. Some of the patches incorporated, some left. Including UI updates, and support for import export.

Some planned features: Notifications of SAML artifacts, support for IdP Discovery protocol.

Federation Lab › OpenID Connect

We’re making progress. In Februrary we’ll be able to connect the front-end test run UI with the backend test tool, and present to visible results.

There is an interop event in San Fransisco, then a new OpenID Connect meeting in Paris next to IETF. Roland is attending to IETF + Kantara meeting. Andreas might as well. We will have some demo available before that.

The backend test tool is able to produce test results for the initial simple test cases, it is tested against several OpenID Connect Provider implementations.

We’re planning on preparing test fascility for OAuth 2.0 in addition to OpenID Connect. That tool might be very useful for the VOOT work.

RedIRIS will perform an implementation of OpenID Connect that will be coordinated with the test fascility. RedIRIS already have experience and a library for Oauth 2.0, and will make use of that. They will also make an simpleSAMLphp module to make it very easy for enabling OpenID Connect support in an existing IdP or SP running SSP.

VOOT

Leif: Setup http://openvoot.org and prepared a drafted IETF templated spec.

Foodle: no updates.

UNINETT has implemented OAuth 2.0, and tested against Leifs implementation. Some problems, but we made it work. OAuth 2.0 support will be integrated into Foodle, this spring.

SurfNet: Ready to exchange OAuth keys with Foodle, is ready to also consume groups from Foodle as a client. Will implement OAuth 2.0 in second half of 2012.

Renater: Has already completed sympa VOOT OAuth 1.0 based implementation. OAuth 1.0 based implementation is made publicly available. Prepared to test against Foodle and SurfNet. Working on OAuth 2.0. Exepcted to be ready March 2012.

SAML2int

The SAML2int profile is being transferred to Kantara Initiative: Federation Interoperability WG.

Scot is will apply some minimal changes contribued by Ian Young.

Federated Provisioning

Mads Freek have been hired by Wayf to work on – mostly – Stinus.

Stinus is the ‘Federated provisioning and de-­provisioning’ project originally proposed by WAYF, SURFnet & JANET as per the enclosed pdf.

A description – one month old – of the architecture is available here: http://code.google.com/p/stinus/wiki/StinusOverview?show=content

I expect to have a pre-poc up an running in week 6 and expect to update the description to reflect some recent changes – mostly the use of Gearman both inside core and as the protocol between Stinus components.

Working prototype within 2 weeks.

Wayf will ensure comatibility with connectors used from the Sun provisioning Framework, that also used in Netherlands. Wayf and SurfNet is in dialogue.

Remco has already done some work on Federated Provisioning, will also do much work in the year to come, but it will be funded by another project. Remco will share a deliverable related to the work on the mailinglist.

DiscoJuice

No updates.

Moonshot

Technology is settling down, more mature, and spec.

Most activity on supporting customers on piloting activities.

Piloting activities around these areas:

  1. Classic e-Science fascilities. SSH access, visitors with physical access to console.
  2. UK National Grid Services.
  3. Cancer Research UK: for microsoft exchange, file sharing, etc. Large organization, divded into 5 institutes.
  4. UK National Health Services. Interested in starting piloting.

Likely initial most important use case: federated login to regular desktops (between different, unrelated MS Active Directory domains), not just applications

Other topics

  • Hot topic: GEANT 3+
  • Convention in Madrid for activity leaders, 27th February.
    • Trained on methodology for GN3+ methodology.

Next meeting in the beginning of March

About opt-in and why it is your fault

Nicole Harris criticizes the Opt-In model in eduGAIN in her article “So, how does that work?”. I completely agree with most of her points – but these problems goes deeper than eduGAIN — and here follows a challenge back at UK…

What can Inter-federation Do For You?

An important basic principle of Inter-federations, is that it doesn’t add much new functionality – it extends functionality – spatially :). Inter-federations will not solve issues in local federations. Inter-federations only connect the common functionality that overlaps, making it work on a inter-federation scale.

The Scalability Issue

Even though a feature or a workflow is available in two federations, and work perfectly fine in local context — if they do not scale, they do not scale — and hence may not work at all in inter-federation scale.

What functionality is needed

Maybe a bit simplified, but if we want a smooth operation of Federations and Inter-Federations, from the IdP and SPs perspective, these functionalities and work flows needs to be in place:

  • Metadata distribution
  • Basic Policy
  • SAML Deployment Profile
  • Attribute harmonization and Attribute Release Policy
  • Peer Connectivity Handshake

Metadata distribution

The technical base layer that needs to be in place before anything work, is two entities to have exchanged metadata. To make this scale, it needs to be done automatically. Most federations has this in place. The «automatic» part is missing in some federation, often in federations built on a hub-and-spoke model.

Basic profile

Before any entities would like to connect to each other in anything but test environments, there needs to be some business agreement. Most federations do support that, and makes it scalable by doing a contract between the federation and the entity instead of the entities with each other.

SAML Deployment Profile

Most federations does not have a clue about this mine field, because they are entirely based upon the Shibboleth software. Shibboleth works very well — with Shibboleth…

There is probably not a single product that follows the SAML specification 100% (this is not entirely taken out of the blue). Even if products follows the specification, there is an very high risk that two deployments has interoperability issues, unless several aspects of the configuration is agreed upon and tested in advance.

Who will encounter interoperability problems between entities? — not the federation, not the Service Provider, not the Identity Provider — but the end user. Most federated application together with SAML software have really poor user experience when an SAML-related error occur.

CC: Flickr, Frerieke

Attribute harmonization and Attribute Release Policy

Attribute harmonization is to some extent handled by eduPerson and SHAC. If you represent a federation, you probably think the harmonization is fairly ok. If you are a Service Provider (I am) to a bunch of European federations, you probably know better.

Attribute Release Policy is much simpler. Still, only a small subset of federations have that in place. Feide, Wayf, Haka (and may be some more) has that.

Those that do not have that in place, such as UK Access Federation (correct me if I am wrong), requires SP admins to make phone calls to IdP administrators to request attribute release. It does not scale very well in a local federation, and it simply do not work at Inter-federation context.

Automated Attribute Release gives the federation the responsibility to quality assure the requested attribute release requests from Service Providers, and Identity Providers blindly follows the decisions made by the Federation.

Peer Connectivity Handshake

Even if an SP and an IdP got metadata right, share a policy, deployment profile, harmonized attributes, and got everything they need to be able to talk to each other, it is not necessarily the case that they both want to. Some Service Providers wants payment for content access, others are only relevant to a subset of the IdPs.

What I call peer connectivity handshake (got any better name?) is the process of a Service Provider to express which IdPs it wants to connect to; and for the IdPs to express that they accept connectivity.

Summarized: The information about which IdPs each SP accepts, and which SP each IdP accepts.

My understanding is that vey few federation has this in place. I’m not aware of any but Feide, but probably there are some.

Opt-In or Opt-Out

If you interpret «Opt-Out» as «everything works unless you manually tell it not to work», that is not an option if you do not have all the functionalities and work flows automated as mentioned in the previous section.

If you got a bunch of federations with missing work flows, you really should not expect the Inter-federation to help you with that. Each federation would need to prepare the workflows locally, then Inter-Federations may help interconnecting it.

Simply because things will not work out of the box unless you got all these; the «opt-in» part is representing letting each entity take care of the manual work flows and functionality that the local federation does not yet offer a solution to.

When the «Opt-Out» model have been discussed in eduGAIN, it has been interpreted as «we will distribute your metadata even if we know you want be able to connect to anyone before you do some manual steps».

eduGAIN

eduGAIN, the European Inter-Federation that you definitively will hear more about next months does support metadata distribution using centralized metadata aggregation. The central component is named MDS (Meta Data Service).

eduGAIN have done great work defining a common lightweight policy attached to eduGAIN.

eduGAIN does specify in detail how participating entities should be configured, and how they should act, increasing the chance of interoperability, trough the use of the saml2int profile.

It is not reasonable to expect eduGAIN to fix local federation work flows. eduGAIN will not scale well, and will not be smooth in the first round – but eduGAIN is not to blame for it. eduGAIN v1.0 will be an important step in the evolution of inter-federation. Local federations’ willingness and enthusiasm for improving scalability in local federation work flows sets the bar for the second round.

The Kalmar Union

The Kalmar Union is an operational Inter-federation, that connects together Norway, Sweden, Denmark, Finland and Iceland.

Kalmar uses the same model for metadata distribution, got a policy, and relies on saml2int as well. But in addition, the Kalmar Union supports automatic attribute policy release.

The Kalmar Union got sufficient functionality and work flow in place to start thinking of Opt-Out. In fact, parts of Kalmar is already supporting Opt-Out. That goes for most of the Identity Providers.

This means that a Service Provider connecting to Kalmar would more or less automatically get things working with all nordic Identity Providers – without doing phone calls.

But PEER fixes everything, right?

There is a lot of fuzz around PEER. PEER does not solve any of the concerns mentioned above. PEER is a third party registry for metadata.

PEER may end up delaying Inter-Federations, like NAT delayed IPv6. Or it may result in a lot of good harmonization work on metadata content, extensions and usage; that actually accellerate and simplify the process of implementing Inter-Federations like eduGAIN. Time will show!

Launching Federation Lab

I’m happy to make an early announcement of the availability of the Federation Lab toolkit.

We would probably make a broader announcement after receiving feedback from the early testers.

The initial set of tools and content available on Federation Lab is somewhat limited. There is plans for improving and extending the set of useful tool during the rest of the Identity Federation project period. If you have ideas for tools that would be useful, please tell us…

What can you do with Federation Lab today?

  • A Service Provider Registry using SAMLmetaJS (javascript editor) for registering your test entities
  • Automated SAML Service Provider Tester: automated testing tool.
  • OpenIdP: Feide OpenIdP will automatically trust all test entities that are registered. A dedicated FedLab OpenIdP and TestShib are beeing configured soon… We will be contacting commercial vendors and offer them the opportunity to connect test IdPs to the FedLab.
  • Web-based SAML debugger. Encode and decode messages captured in the SAML flow.

https://fed-lab.org

Video demonstrating how Federation Lab Works

I’ve made a short screencast demonstration of how Federation Lab works.

SimpleSAMLphp takes part in Kantara Initiative SAML 2.0 Full Matrix Conformance Testing

SimpleSAMLphp has been formally selected to participate in the Kantara Interoperability SAML 2.0 conformance testing.

UNINETT signs up for conformance testing of SP-Lite and IdP-Lite. We are looking forward to getting into this. Both to get a more formal conformance stamp on our SimpleSAMLphp product; but also to learn more about interoperability between SAML 2.0 products, something that we’ve been working pretty much on lately.

The test event will be held from January 6 to February 24, 2011.

Comparing saml2int with eGov 2.0

Mikael Linden has done a great job doing a comparison of saml2int 0.2 and eGov 2.0. Here is the highlighted major differences:

  • eGov requires some PKIX support
  • eGov supports artifacts and related SOAP binding
  • eGov supports Holder-of-key (conformance class “full”)
  • eGov has a more detailed IdP proxy support (conformance class “full”)
  • eGov supports SLO protocol (conformance class “standard with logout”)

A document with a more detailed comparison is available:

Updated: the detailed comparison document was added September 6th 2010.

Federation Lab : Automated SAML 2.0 SP Compliance Testing

I’ve started working on an automated testing tool for validating behaviour of SAML 2.0 Service Provider implementations and deployments.

I’ve just started the work, and a public test user interface will be available later. For now, enjoy this video teaser…

I spent quite some effort on making this video playable on all modern browsers, iproducts, and using HTML5 at the same time. If you are not able to play the video, please let me know…