• Created by Unknown User (schofield), last modified by Unknown User (roland@catalogix.se) on Feb 13, 2014

TF-OpenSpace – Session 5, room yellow.   12 February 2014. 

Lead by: Roland Hedberg

Attendees: Peter, Joost, Rhys, Licia, Martyn, Thomas, Rok, Blaž, Christos.

Notes: 

Roland started with an introduction to OpenID Connect (OIDC) and an outline of the main differences between OIDC and SAML2.

  • java web tokens (JWT) instead of XML,
  • No SOAP, PAOS or such stuff, only HTTPS GET and POST.
  • As the result of an authentication you don't get an assertion, you get an access token which can be used to get user information any number of times until the token expires.
  • No metadata, dynamic provider (IdP) info retrieval and dynamic client (SP) registration.
  • The default user info schema is very simple (what you would get from Facebook, Google,...). No organization info, entitlements, affiliation, roles, ...
  • Implementing a OpenID Connect Provider (OP) is still some work, implementing a Relaying Party is fairly simple.

The question to discuss is what would we need to add to OIDC as it's defined today to replace our SAML federations tomorrow (a though experiment).

  • Obviously we would have add a more complete schema. We could either import the LDAP schemas as SAML has done or go for SCIM.
  • If only authentication is needed (CLARIN style) then no 'federations' would be needed.
  • Federations might play a role if we want to user 'entity categories' in OIDC. Service providers could then pre-register at the federation and get an access token to be used when registering the client. The access token could be a signed JWT containing information about which categories the client belongs to and also information that binds the token to just one client or a set of clients.

Other things discussed:

  • There are already many OP implementations (~20) a couple of the open source
  • There exists OP and RP implementations for smart phones/tablets.
  • step-up authentication supported out-of-the box.
  • Support for encryption/signing algorithms other than RSA.
  • The security of OIDC is to some extent dependent on secure DNS and SSL.

 

[ACTION] 

We should start a pilot with a few interested parties to flesh out the problems.

  • No labels