OAuth is coming

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

• Attribute query protocol
• Certificate enrollment in confusa using OAuth

• Virtual Organizations, OAuth and trust models
• Twitter authentication model

House RFID tag privacy?

My house was tagged with a little RFID tag yesterday.  It sits quietly inside the door jamb, under a sticker with the logo of the cleaning company.   When I got the CTO job, a condition from the family was to get cleaning help, and we got a company to come and clean the house.  They do a good job, and they work hard.

I suspect that the reason for the tag is to be able to change our bill if the cleaning of our house consistently runs over time, and to keep track of employees who slack off compared to others.  The latter is related to privacy, the first is economics.

The company sent us a letter two weeks before the sticker was applied.  The main topic of the letter was informing us about the sticker, since it sticks to stuff in our house and they would like us not to remove it by accident.  The main text was about how this RFID was not in any way an invasion of our privacy, and that it had been cleared with the Data Inspectorate.

On one hand, this was encouraging, since privacy obviously was a major topic that needed more text than the simple fact of redecorating our entrance hall.  On the other hand this was discouraging as the privacy invasion is on the part of the company employees who will now be monitored on how much time they use in each house, and this was not the focus.

 

Attribute aggregation and virtual organizations

Some interesting postings om attribute aggregation, both grew out of work on virtual organizations

• VO Proof of Concept using Shibboleth simple attribute aggregation ready (Lukas Hämmerle)
• SP-Centric Attribute Aggregation (Andreas Åkre Solberg)

Attribute aggregation is collating attributes about a user account from multiple sources.  In the case of virtual organizations and their use of specific web resources with federated login, this boils down to: how do I add an eduPersonEntitlement maintained by VO-whatnot to the information about the user from his university.

The possibilities and the doors opened with attribute aggregation are enticing and slightly frightening. My international research project site getting an attribute from the project manager and federated login from my employer will work fine.  That is not scary. The employee web site may be able to download info about my color preferences from nerdy-color-repository.  That is not so scary.  When my son starts school next year, I may log in to the learning management system, getting the login from the national eID, the association with my child from an attribute authority and information about his attributes from Feide.  That is cool and not scary at all.  The pizza place getting info about my phone number, cross referencing with payment history, getting info on pavement status in my neighbourhood and refusing to dispatch pizza to the people helping me move my piano.  That is scary.  And partly why the user interface for aggregation, informed choices, privacy, security testing and a lot of other issues needs more work.

Informed consent and necessity

Normally we try operate all transfer of personal identifiable information by the principle of informed consent.  In the discussions on privacy at the NORDUnet conference, Andrew Cormack pointed out that in practice the guiding principle for services may well be necessity to transfer and process personal identifiable information. Privacy guidelines explicitly allow processing when there is necessity, as illustrated in the figure below.

One example of necessity is if my hospital need to notify my family physician that the xray pictures show a rampant pneumonia.  Not notifying the person responsible for prescribing antibiotics may harm my health, and in this situation the necessity is easy to understand.

In the EU regulations, the necessity part seems to be interpreted differently from country to country.  Denmark has legislation allowing parts of the public sector to exchange information according to necessity.  In Norway this is put into some specific laws, but is not an overall guiding principle with a carte blanche.

There is discussion on what constitutes similar services, and if informed consent to transfer information needed for exam registration is really voluntary when the alternative may be to travel for 20 minutes and spend an hour in an office to complete the same transaction on paper.  If the prior procedure was all on paper, and the web self service interface was introduced as a complement to standing in line, the answer may be that it is voluntary.  If the procedure was on the web, and the paper procedure was added as a fall back, then it may not be voluntary enough.

This then raises the question of who gets to impose what costs.  May I as a user impose the cost of a paper procedure to may university, but gain the feeling of online privacy?  If this is only a feeling, and the university processes my PII data together with everyone else, the only gain for me was avoiding Internet transfer.  Does that make sense?  Does it make sense for stuff that must be conducted online?  Or does it only make sense in those situations where I do not trust the service provider?  If I have to trust the service provider to handle exams, I may have to trust them with information in order for them to provide my credentials.

I am not sure what to think about the necessity part of privacy.  But I do know that keeping users informed is polite, and politeness is necessary.

Launching Kalmar2

It’s my pleasure to inform you that Kalmar Union, the
confederation of Nordic academic identity federations,
is operational and today published in the NORDUnet conference.

Press release:
http://www.kalmar2.org/kalmar2web/kalmar2_is_open.html

Kalmar currently covers all Danish and Norwegian universities,
6 Swedish universities and 1 Finnish university. 10
Service Providers are registered to the confederation.

NORDUnet2009 presentation with lots of help from Mikael Linden, David Simonsen and Andreas Solberg.

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.