IdM with multiple LDAP sources

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

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.

Common Identity Framework, comments

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?

National identity

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.

LoA from Australia

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.

LoA work from JISC

Levels of Assurance is one of the hot development topics in federations. JISC published the final report of JISC LoA work in November 2007 from the ES-LoA project. The project collected requirements from service providers, identity providers and universities in the UK. They also investigated existing LoAs, and looked into requirements in higher education and research.