TIIME 2015 Session 6: Dynamic sca/aS/e metadata exchange

Conveners: Michael Grabatin, Daniela Pöhn

Abstract: A different approach on the communication in between an IDP and a SP without the usage of a proxy as the third party but instead using GÉANT TrustBroker. This approach has many advantages compared to proxying and the first and most important one is the simplicity in the architecture, as it requires only a one-time authentication and none more afterwards.

Tags: Trust, SAML metadata

Goal: dynamic metadata exchange workflow, orchestrated by a trusted third party.

Background: https://wiki.geant.org/pages/viewpage.action?pageId=45844180 (for more information)

Identity provider (IDP) and service provider (SP) do not technically know each other beforehand, exchanging the data on demand via a trusted third party (GÉANT TrustBroker).

The core workflow is explained:

• The user selects his IDP at the trusted third party (TTP), is used to authenticate
• The authentication request of the SP is cached at the TTP and a new authentication request is generated to the IDP
• After successful authentication of the user, the metadata is exchanged and then integrated
• If the SP needs other attributes, then the IDP has currently, conversion rules are needed
• Attributes are user information with some semantics and syntax
• IDP and SP might have different format -> Attribute conversion rule can be provided by the TrustBroker.

Business goals and purpose of the metadata exchange between IDP and SP via a TTP:

• Scalable approach in order to have less problems with parsing the aggregate
• Provider does not have to join another federation or set up their own federation.
• Simple workflow integration. Administrators can be notified by e-mail and asked if they allow the connection

Q: Why is it better than proxying?

A: Because the TrustBroker is only involved in the first metadata exchange, for all following authentications it is no longer involved.

Q: Do you have an IDP black list?

A: Yes, there are black-lists and white-lists to limit which providers can exchange metadata

The provider administrators want as much control as possible about who they are trusting and which attributes they are releasing.

The discovery part is not in the main focus of the TrustBroker, many projects trying to solve discovery problems. It might be combined with something like AccountChooser.

The metadata exchange can be rolled back.

Q: Why is it dynamic?

A: It is exchanged on demand, when the user first accesses a SP

Comment: A real advantage would be a complete workflow engine, because access decision need human decisions, possibly from several persons. Example: the user would hit the SP, the SP would request the IDP to be allowed (the user would have to wait anyway). The IDP might decide later if the SP should be connected. The user would be notified that the connection is enabled.

Video showing the user experience of connecting a SP to a IDP: https://wiki.geant.org/download/attachments/45844180/2nd_shot-3.mp4?version=1&modificationDate=1435041552887&api=v2

Some projects are outside eduGAIN, they have a problem exchanging the metadata.

The metadata is regular SAML metadata. For the communication with the TrustBroker additional fields have to be added in the extension field.

Laas:

We take only entities from eduGAIN that have validated their attribute release policy. This is done by hand-picking, which causes the scalability problem. CoCo and R&S entity category help.

The metadata distribution has problems on different layers:

• how do you transport securely
• how do the processes work

The processes are currently often not in place or manual.

-> The TrustBroker offers a simple workflow, that sends an email if asking the provider administrators if they allow the connection

Rainer:

If you have a workflow you need some kind of a scheme for it, you have to define your custom workflow.

Laas:

I would want to know that the IDP is not an anonymous group of hackers. -> Signature verification, registration

Conclusion

Q: How to actually improve on the trust of the metadata?

A: If you have this small virtual organisation (VO) enter the federation. Getting a letter from the dean could be added to the connection application, to prove the connection is needed and authorized.

Q: How do you establish trust?

A: The dynamic registration the TrustBroker implements (similar to OpenID Connect) seems to be not trustable?

The workflow is the key component, not the metadata exchange itself. Move focus from technical trust to workflow support.