David Bantz posted an interesting email Please, somebody talk me down! on the Shibboleth users list, pointing to four issues that crop up over and over again with SSO in higher education:

  • Even if a vendor claim to support SAML, they are unable to consume attributes. And the provisioning of attributes include both sensitive, restricted and open information.
  • Proprietary extensions are used for too many of our solutions
  • Credential relays, operated by non-trusted third party (or SP). Preferably combined with non-maintenance of SP software?
  • Why not just use AD? Believing that using AD will automagically  integrate all services.
The scary summary is that we as a community are not providing enough direction when it comes to SSO solutions.
For some of these issues (why AD does not solve all problems, credential relays) we need to explain the issues in a language that may be understood, or even better, put into calls for tender. For other issues there are unsolved technical problems, like the integration of web-SSO and non-web-SSO.  The concept of real-time attributes, so beloved of higher education federation, is poorly understood by most vendors. Then again, they are not used to operating in a world where user account lifetime is planned per semester.
I am hoping that REFEDS may be a place to work on some of the issues pointed out, but the bulk of the work will have to be done by each individual university as they call for tender and discuss with their application suppliers and partners.

We have been playing some with the ideas related to gathering third party attributes, and what we could enable.  Two important use cases

  • Virtual organizations: Who do I need to collaborate with?  Where do I find the project/VO tools? Where is our common space?
  • Universal access: What are my preferences with regards to text, speech, sign language or video?

The Tabia project presented a prototype using Feide for managing the preference service and oAuth for anonymous sharing of preferences, and with the added benefit of using Feide for SSO between multiple services.  Tabia was discussed at the Kaleido conference in Tromsø today, where a workshop aimed at hashing out the main issues involved with a preference service for universal access, given that children have the right to universal access to individualized education.

My presentation at the workshop centered on identity layer and preference storage (Norwegian language), what is possible when we have both federated identity, oauth and standards for universal access.

If for example I want to roll out web conferencing tools to a couple of hundred thousand users, and all these users have a federated ID linked with a good attribute set, why should I have to worry about provisioning?  I can have my users log in, transfer the appropriate information as attributes, and then things should work.  And there are at least 15 million federated user in the higher education sector alone, across the federations that we know of.  Why are the solutions emerging so slowly in this market?

We spent the last decade fixing availability of attributes and getting federated IDs deployed, and I would like to reap the benefits I know are lurking in the cloud from this investment:

  1. Federated login without letting the applications see the passwords
  2. Let real-time attribute transfer replace provisioning
  3. Being able to let federated widgets play together to let components form a coherent service, easing integration

Getting back to my current use case on web conferencing tools, I get really frustrated.  Not only with the bad audio, which is seriously annoying, but with the cumbersome deployment issues when rolling out in large communities. As far as I know, there is only Cisco WebEx of the web conferencing tools that have federated login operational on their standard federated plattform.  Some other vendors and solutions are actively investigating federated ID, and have customers who have done on-site extensions with federated login.  Some comments on web meeting solutions I have encountered in the past few months

  • Adobe Connect, a popular solution in higher education for web meetings does not support federated login on their hosted environment.  An example a properly behaved system  is SUNETs Adobe Connect installation where SUNET has added federated login with SWAMID and support for attributes.  Why not on the hosted service?  Will it be too much trouble to get a large amount of users?
  • Elluminate is working closely with several major LMS suppliers (it was bought by Blackboard this summer), and has functionality that is useful for education.  But no federated login – yet.
  • Nefsis is highly loved by the teaching community using it. I have not been testing this system myself.  There is no federated login.
  • NTR-meeting is a lightweight solution for web meetings, simple and easy to use.  Would be even easier if it had federated login.
  • BigBlueButton is open software for web meetings.  Not quite in production yet, and has no federated login.
  • DimDim is also used for distance lectures.  But it has no federated login.
  • Vidyo is tested (I have not tested it myself) by several interested parties.  No federated login reported.
  • EVO from the high performance computing crowd.  Developped within our own community.  Still no federated login.
  • Microsoft OCS may support federated login (codename Geneva), but when I talk to the local guys about this, we have so far spent most of our time explaining that federation does not imply collating Active Directory trees, but is Something Web with XML.

And the service from Skype, useable with good sound when everything else fail: no federated login.  On the other hand, I did not expect Skype to have federated login, as they operate in an environment on individual users.  The ones named on the list above try to deliver services to organizations.  Deployment without federated login is a lot more work than with federated login.  On the other hand, the extra work falls mostly on the deploying organization, so maybe that is why the service providers do not care.

An interesting presentation on  design criteria for social web sites, with discussion of how the multiple facets of identity are not supported in most online social networks.  The presentation is interesting both from the directly applicable design of groups/roles and the discussion about how to handle attributes and information flow within social web sites.

At the same time we see an interesting uptake in the use of social web sites and channels to discuss (and cut the lead time of scientific discourse) things like Analysis of Vinay Deolalikar’s recent preprint claiming to prove that P != NP.

SURFnet published a video on how the Dutch research network is proceeding with its innovative Collaboration Infrastructure project COIN.  This work is a synergy of federated identity, social networking and collaboration tools.

Applications should perform well in the environment where they live.  Requests have been made to domesticate applications for higher education.  Some key elements we ask for in a domesticated application

  • federated login (in our case: support SAML2.0 with the SAML2int profile)
  • never touch a password, login is handled in the federation (in our case: Feide)
  • consume attributes as defined by eduPerson and additional schemas (in our case: norEduPerson, eduOrg and eduOrgUnit)
  • have a reasonable privacy statement, and act accordingly (in Europe, se Article 29)
  • if there is need for provisioning, have a well defined provisioning API (in our case: PIFU)
  • support virtual organizations and external group management

These requirements are basically the same as you find when people build their private cloud systems from open hosted applications.

The discussion on these issues started among federation people operating university identity federations.  Victoriano Giralt says that

“domesticated application is on that has been adapted to federated access management in some way. I’d even dare to propose levels of domestication:

  1. Domestic species. FIAM has been put in by design, with delegation of AuthN and AuthR to the federation.
  2. Petted species. The application design has allowed to create an AuthN(R?) plugin that allows it to smoothly integrate to the federation, maybe with a minimal local user provisioning.
  3. Tamed applications. They have been made to play in the federated environment by way of provisioning local users on the fly with kind some kludge, but AuthN/AuthR happens mostly at application level but with information carried over from the federation, but do not ask for username and password.”

There are wild beasts out there!

Some interesting thoughts on SPML were presented in the Burton Group posting  SPML is on life support.  Everyone involved in identity management, at least all those trying to do a good job, spends way too much time on provisioning.  Some of the Too Much Time is spent on non-standard integration, because every single integration has to be hand made.

Hand made integration is

  • expensive (and consultant-intensive)
  • not even close to scaling, since every integration is between two individual systems
  • error prone, since hand tailoring is by definition one shot wonders
  • tailored to the needs of the team specifying the integration, usually not the needs of the organization as a whole (unless there is a clear architecture)

The two main alternatives to provisioning both involve exposing information from the distributed infrastructure

  1. Virtual directories and local LDAP exposure.  This is a chilling option to those of us who know details about everyday LDAP security practices.  If people knew how to install SSL and close off parts of their directories, I would be less scared.  But still scared, since exposing LDAP servers directly is an elevated art.
  2. Federations and SAML event-driven information exchange.  This requires changes to the usual workflow for provisioning, but is a feasible alternative.

Groups and roles are not easy to share across applications, and this needs to happen in an understandable secure solution space.  Emerging work on virtual organizations and multiple attribute sources for federated login looks promising, but is not likely to deploy in production real soon.

It looks like provisioning will be an area to watch, simplify and spend Way Too Much Time on – yet another year.

Am I being too pessimistic? I hope I am.

and we like it!

OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications, as stated on the OAuth web site.

Why do we like OAuth?

  1. It is simple.  Most of the bad security implementations are done by people with good intentions and low skill.  Understanding the issues involved greatly improves the changes of making the right choices.
  2. It solves a real hard problem: giving access to your stuff without sharing your identity.
  3. Plays well with others.  OAuth has built in support for desktop applications, mobile devices, set-top boxes, and of course websites.

OAuth helps delegating rights to a process acting as you, without losing privacy or compromising security.  And the specification is short and possible to understand.  Replacing shared secrets is a really good idea.  Replacing hardcoded application-based passwords is an even better idea.  Replacing spoofing of user by logging in as root/admin and then emulating the actual user is a great idea.  And all of this may be done by OAuth.

One use case is getting access to your data on your behalf, but on a different site while not giving away your identity from the first site. Another is the TCS eScience Personal Portal (aka Confusa) that will use OAuth to authenticate a command line client tool to a web-based service that issues short-lived certificate. Then they will extend it further using OAuth for web-based delegation of proxy-certificates; collaborating with a Norwegian University.  Some other use cases that people in my neighbourhood has been playing with so far

Next Page »