I love the open attitude at UiO, they share their projects and plans and work online.  The last thing I looked at from them was a brief investigation of the work they have done on group management, and how the group provisioning tools interact with their campus identity management system.

UiO has done work on group management (dubbed WebID, formerly known as VirtHome), and their current group profile holds information about

  • The name of the group (cn, mandatory)
  • Description of the group (description, mandatory)
  • Members of the group (uid or eduPersonPrincipalName, mandatory)

Each user is registered with group relevant information

  • Group membership (member)  DN for the all the groups the user is member of.
  • username (uid, mandatory) Must be unique within the group management tool
  • Full name (cn)  Using cn for full name of a person is a choice made, and non-federated users will not necessarily have this attribute with high data quality.  Federated users may have cn populated by something else but their name.  Tags are used to distinguish federated users from accounts local to the group management.
  • Last name (sn).  Tags are used to distinguish federated users from accounts local to the group management.
  • Given name (givenName). Tags are used to distinguish federated users from accounts local to the group management.
  • Preferred name (displayName)
  • email (email, mandatory)
  • Password (userPassword) Encrypted password for the user, not relevant for federated users.

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.

Feide has an architecture where one Identity Provider has multiple Authentication Points behind the IdP.  Authentication Points are implemented as LDAPs, and all the LDAP servers are using the same norEdu* schemas (norEduPerson, norEduOrg, norEduOrgUnit) building on  eduPerson which builds on inetOrgPerson. This sounds complicated, but in real life this amounts to minimum technical overhead, as the only changes needed in the local technical infrastructure are

  • adding the norEdu* schema to the existing LDAP (since every single institution has at least one LDAP)
  • regular updates of the LDAP from authoritative sources (student registry, payroll systems, school management systems etc)
  • configuring filters for the information from authoritative sources
  • installing SSL/TLS on their LDAP, and giving Feide the certificate information

The identity management itself is mostly an administrative process, and this is the part of process re-engineering and auditing that takes time.

A university or college or school owner have their own realm. Each realm provisions users to their own LDAP, and the IdP looks at all the realms.

Why, oh why, is this not supported in off-the shelf software?  Are there no mergers in business outside higher education?  It is a simple mechanism that allows for integration of several user groupings, and we know from experience that it works.

Sharing, withholding and delegating sounds like advice from Management 101, a first introduction to getting things done.  In the case of identity management, there are some hard cases to crack

  1. Sharing metadata: getting information about the right identity provider to the right service provider, as needed
  2. Withholding information about technical detail from the end user, while giving enough information to make informed choices.  One aspect of this is seamless discovery service, where the before mentioned identity provider information is available when needed, without prompting the end user to input something
  3. Delegation of rights.  I may wish to delegate rights to my husband or to a process running on my behalf (webmail should be able to check my mail account via IMAP, even if IMAP is a non-web protocol)
  4. Aggregation of information about me from multiple Identity Providers, while keeping my privacy and giving a user friendly interface to managing my own information

The discussions on these issues have tended to get into complicated corner cases and some heavy protocol elephantiasis.  The simple and elegant design of OAuth gives some hope, as people start experimenting and throwing connected ideas around.  An example is Andreas’ draft work on attribute aggregation.

Simple is good. Testing various ideas helps us sort out how the issues above prevents us from solving some of the use cases

  • Grandfather wants access to e-learning platform, needs to check on school work and see if grandson handed in assignments.  Depends on delegation of rights from parent.  Depends on discovery service to sort this role from the primary role as professor at university.
  • Parent wants to delegate limited rights to supervise schoolwork to grandfather.  Depends on attribute aggregation from multiple sources, as parent-child relation is independent of authentication method.  Depends on seamless discovery service, since this must be possible for all parents.
  • Integration of Web2.0 applications without total mesh coupling.  Depends on withholding information to preserve privacy, and delegation of rights to several process keeping track of social network updates.
  • Universal access to web sites, while preserving privacy.  Getting information about disabilities (sensitive information) to adjust web sites to end user needs.  Depends on aggregation of attributes from multiple sources and delegation of rights.

The issues need to be solved for user centric identities, organization centric identities and federations.  We are not there yet – but the space needs watching.

Trying to wrap my head around the concepts introduced by Kim Cameron, Kai Rannenberg and Reinhard Posch in Proposal for a Common Identity Framework

Kim Cameron is blogging about definitions for a common identity framework, explaining the concepts behind the paper.

Their definition for user centric is interesting

User-centric: Structured so as to allow users to conceptualize, enumerate and control their relationships with other parties, including the flow of information.

The work in Feide on consent, consent management and revamping user interfaces falls nicely into this definition. When the goal is to give users control over their relationship and give them tools to conceptualize the existing relations, we ended up with the federation Innsyn. I do not fully understand what is implied by “enumerate relationships”, but assume that this is similar to the consent management. It is interesting to note that user centric solutions can be achieved both on the client and server side of the traditional server-client model for services, but in order to do server side user centric solutions, the user must be given tools on the server side.

Another interesting concept in the paper is that not all assertions are true (but all Cretans are liars?)

It is key to the document that claims are assertions by one subject about another subject that are “in doubt”. This is a fundamental notion since it leads to an understanding that one of the basic services of a multi-party model must be ”Claims Approval”. The simple assumption by systems that assertions are true – in other words the failure to factor out “approval” as a separate service – has lead to conflation and insularity in earlier systems.

Being able to sort out assertions into claims and credentials may help us think clearer about the security needs. In psycology we learn that children will know the difference between true and false at the age of three-four, but in this case the security community has taken a few more years to sort out the issue. I wonder what that says about the maturity of our understanding?

Adversity builds character.  Victory builds identity?  First there is the victory of birth, which gives you your birth date.  Then there is the victory of family (or such like) that gives you your name.  Then there is the victory of nations, which gives you your nationality.

Today is May 17th, constitution day in Norway, and this involves a big celebration: children’s parades, brass bands, school bands marching, heavy ice cream eating, sausages, potato-on-a-spoon races, more children’s parades, patriotic speeches, balloons and so on.  The traditional speech starts with “for those of us who experienced the war, 1945, 1905 and 1814” and then moves on to extol the humble origins and humble virtues of the nation.  On the other hand, we celebrate by parading children, not weapons.

Norway is a relatively young nation, we won our independence in 1905, but the constitution dates from 1814.  The national identity is rebuilt and reconfirmed, and history revisited.  Today is the day when every school child in the country march in the parades, on an identity building exercise, dressed up in national costumes or other finery.  Given the normal weather in May, this is sometimes also a character building exercise, as all mittens are off for the celebration (my soul still have childhood scars from frozen fingers gained by playing brass band music outdoors).  This year we had perfect weather in Trondheim, 15-20 centigrades and some wind to lift the heavy woollen skirts of the national costume.

Last night Norway won the Eurovision Song Contest, and our prime minister said that this was a great victory for Norway.  Fun, weirdly entertaining, yes.  Great victory?  That would be conquering global warming, flying to Mars or curing the common cold; or at least that was my initial reaction.  Then it dawned on me that our prime minister was in Spain, about to celebrate Norway’s constitution day with ex-pats and the Spanish prime minister attending the Norwegian children’s parade in Torrevieja.  And the man who won the great victory for Norway was born in Minsk, Belarus, immigrating at the age of four.  The prime minister was right, winning the Eurovision Song Contest was great victory for the national identity, not just another flag waving moment.

Current great victories seem better than the viking approach, or other glorious forefathers.  Glorious forefathers had a hang-up on conquest of the traditional type: rape, pillage and burn (preferably in that order).  Song contests may be better for building identity.

The Australian higher education federation has developed a proposal for Implementing Levels of Assurance in a Trust Federation using PKI and Shibboleth

The proposal was commented by Alex Reid as

in Australia we are going with the concept of a “floor of trust” which is rather higher than NIST’s Level 1 assurance level, as it implies/requires that an independent (responsible) authority (namely the University of an agent of the university) has verified the identity to some degree – more, anyway, than the self-validating Level 1 assurance that OpenID, Facebook, etc provide.

The need for level 1,5 seem to crop up in various contexts, as self-asserted identity is not considered good enough for some use cases.  Those use cases does not want to support the full level 2, with a separate gadget (or one-time passwords), since the cost is deemed too high. We might have to wait for Incidents, to assess if the cost of Level2 is really higher than having multiple Incidents in our community.  Cost-effectiveness of security measures is tricky, as the real cost is know only after something went Wrong.

Levels of Assurance is either a quagmire where the most brilliant minds of our community will fall, or an interesting space to watch.  Could be both at the same time, and we could market this whole discussion as a reality show where we charge enough money from TV to cover the costs of implementing it.