McShib – The Future of Shibboleth

I recently attended McShib, a Scottish Federated Access Management Forum held in Edinburgh on the 24th of February, 2011. Well known Shibboleth developers, Chad La Joie, Scott Cantor and Brent Pullman flew from US to provide us with a roadmap and future of Shibboleth, which I found extremely useful. Considering that I recently jumped into the the world of federated access, I could relate to a lot of frustrations and questions that other colleagues were raising. This also made me realise that I am not the only one who went through those challenges. The good news though is that Shibboleth developers are aware of this, and they are trying really hard to overcome these initial obstacles.

I am going to write down some important points from the presentations for people who were unable to attend but are interested in knowing what happened.

• Revamp of documentation
• Looking for a new stable home for Shibboleth
• Enhance attribute resolver functionality in future, which means you can merge attributes at SP, drop scopes, or do some other things with an attribute on the SP side.
• The audit logs will be revamped, in Apache shortcode styles which you can use. E.g. %D, %u, etc. You can chose whichever detail you want to go in. You can therefore feed that into log analysers, e.g. AWStats.
• Embedded discovery service (1.0 beta) releasing very soon. Consumes data from SP 2.4+.
• The centralized discovery service will also have a major release soon. It will use the embedded DS as UI.
• The centralized DS will also package a Servlet container within itself, so it lowers the learning barrier for that.
• IdP 3.0 (major release) – separate credential extraction from validation. (As an example, to dig up things easily from a packaged message). This might be useful for sending credentials through software rather than a browser and then digging response from the returned packaged message.
• SPNEGO support (so you login to active directory means you login to your IdP).
• Conditional evaluation will be introduced, e.g. if the username is @student, it goes to one LDAP directory, and if the username is @staff, it goes to another.
• Out of the box attribute consent engine, similar to uApprove (Shib documentation has screenshots for IdP 3.0).
• Performance metrics will be introduced for IdP, e.g. that filter policy is taking a long time to run, e.g. that LDAP server is not responding in time, etc.
• IdP 3.0 shipped with installer configured container (again lowers learning barrier).
• Metadata Aggregator (to overcome the so called national boundaries).
• ETag and Last-Modified based conditional GETs for metadata. Already supported by UK metadata servers. Not gzip compression yet though.
• Metadata is now reloaded in a background thread. IdP 2.2 and SP 2.4 supports this.
• Dynamic metadata retrieval
• Just in time fetching of metadata by entity ID.
• As Sha1 becomes weak, rollout of new cryptographic algorithms is becoming an important question. However, rollout can cause problems. Does your relying party support the same, e.g. Sha512.
• In future, simple string attributes will be supported for release filter policy which is based on entity attributes (e.g. EU, so release the name attribute, US so don’t).
• For better UI purposes, the metadata has two new extensions.
  • UIInfo – display name, description, logo, keywords, information and privacy URLs
  • DiscoHints – IP Address ranges, domain names, geolocations. This is used for sorting purposes in the discovery services. Discovery service will not automatically pick or remove an IdP on this basis.
• Regarding SP UI, there should be a focus on Lazy Sessions and use of isPassive (do not disturb the user unless absolutely necessary). True SSO experience.
• SP UI should use errors that tell a user to contact the support team of the organization in question, not their home organization.
• Regarding IdP UI, it is recommended that you put your contact information on all pages, including error.jsp, login.jsp and consent pages which are *.jsp. Put your branding on all pages as well.
• Keep the login page as simple as possible. Keep each page focussed on one job.
• Detect and trap lack of LoginContext
  • Happens when people bookmark the authn page.
• Install uApprove
  • Even if consent isn’t required, informing the user is a good thing.