//dennisbloete

Freitag hatte ich das letzte Kolloquium zu meinem Bachelor-Report (Abschlußarbeit zum „Identitätsmanagement im akademischen Umfeld“) und bin nun fertig mit dem Studium! Jetzt warte ich zwar noch auf das endgültige Zeugnis, das dürfte aber recht zufriedenstellend aussehen

Im Rahmen der Abschlußarbeit habe ich einen OpenID-Server für den Fachbereich 3 der Uni Bremen entwickelt. Rückblickend bin ich wirklich zufrieden, da das Projekt viel Spaß gemacht hat, mein erstes größeres Open Source Projekt masquerade entstanden ist und ich auf dem Studiumsendspurt noch einmal viel mitgenommen und gelernt habe. Teilweise recht anstrengend empfand ich die schriftliche Ausarbeitung (mit der ich im Nachhinein auch nicht ganz zufrieden bin), weil ich mein Interesse doch eher im praktischen Teil lag. So ist es aber gut zu wissen, dass man auch am Ende seines Studiums noch einiges dazulernen kann (streng genommen war das meine erste wirkliche wissenschaftliche Ausarbeitung) und die Software soweit einsatzfähig ist, dass sie im kommenden Semester dann auch ihren Praxiseinsatz erfährt.

Nach drei Jahren Studium soll es das jetzt erst einmal gewesen sein und ich habe wieder richtig Lust drauf, an Real-World Projekten mitzuarbeiten. Das Ausschlafen und die flexiblere Freizeitgestaltung werden mit sicher fehlen, aber wenn ich dann keine Lust mehr auf Arbeit habe, kann ich ja immer noch den Master hinterherschieben

Technorati Tags: Studium, OpenID, Arbeit

In one of my last articles I wrote about Attribute Exchange and how this namespace can be used to exchange whatever personal data you like. You are not bound to a fixed set of attributes like the one that the Simple Registration extension offers, because you can define your own type identifiers.

In case you want to get more advanced and use OpenID for lightweight identity management this essential, because you probably have to exchange data other than the eight attributes offered by SReg – for instance an address or phone number. This can be done using AX and as long as Relying Party and Identity Provider support the same set of attributes/type identifiers there is no problem. There aren’t many IPs and RPs with AX support out there yet, but this will improve as with AXSchema.org there are already some type identifiers defined that both sides can pick up and support.

At the University of Bremen we are implementing an OpenID Identity Provider so that students can use their OpenID to sign up for courses, log into elearning systems and prove their student status. We need to exchange attributes that are typically used in higher education like matriculation number (somewhat comparable to a student id), their affiliation and degree program. This is beyond the scope of what is already defined at AXSchema.org and so we needed to come up with our own attribute type identifiers.

Reading about how to do that, you will come across an article by Chris Messina in which he talks about looking for existing standards that you can build on top of. As an example he mentions the vCard which could have been used to associate attributes with an already standardized name – unfortunately it was not and now attributes are named differently in SReg and AX. This is an important point as there are so many existing standards out there, but somehow we tend to always reinvent the wheel – even nowadays. If you would like to dig further into the discussion of how to combine OpenID and vCard you can read Tantek’s Toughts on this – he offers a modest solution for the problem, too.

I finally decided to turn to Shibboleth and it’s EduPerson object class which includes names for some of the attributes we need to exchange. What I could not find there I took from what the DFN-AAI and SWITCH had defined – here are the resulting schemes.

Conclusion: Watch out for existing standards if you have to define your own attributes as this will at least offer the option for portability in the future. There is a lot of work to be done in standardizing much more attributes than the ones defined by AXSchema.org, but Attribute Exchange already offers enough possibilities to use OpenID for lightweight identity management – especially when you are dealing with a known circle of IPs and RPs.

This post and the decision to use EduPerson and the attributes defined by the DfN was inspired by some discussions I’ve had after giving my talk on Attribute Exchange and defining attributes (slides are in german) at the IdentityCamp Bremen two weeks ago. Thanks at Henrik Biering and Tobias Marquart for their thoughts on this.

Technorati Tags: Attribute Exchange, AX, openID, Shibboleth, EduPerson, DfN, hCard, Higher Education

I first came across the Yubikey listening to Episode 141 of Security Now and thought that it is pretty interesting thing. After listening to Episode 143 – which is all about Yubico and the Yubikey – I was convinced and ordered one to try it out: I received it last week and played with it over the weekend – this thing is so cool that I directly integrated support for it into masquerade…

What is it all about?

The Yubikey is a new authentication device – a USB-keyboard with only one button.

The user inserts the YubiKey in any computer with a USB port on any platform or browser – no client software install needed – then press the YubiKey button to generate a one time passcode.

You can add it to your keychain, insert it into every computer you work on and use it to authenticate yourself without remembering a password… it requires no battery and is so easy, that even your mother could use it, since there is only one button to push

But wait: This is the point where I have to mention that the website that asks for authentication (lets call it the relying party) has to support Yubikeys… this is a disadvantage of course, because at this point there are just a handful of public sites on the internet that authenticate via Yubikey. Even though it will take some time until this will hit the mainstream, the Yubikey is the perfect solution for todays intranets or other websites that require multifactor-authentication. And it is so easy to integrate, that adoption could spread rapidly…

I won’t go into further details about what the Yubikey is and what it can be used for, because there are other good resources on that out there and I want to talk about how to integrate authentication with Yubikeys. Just consult the Yubico website or listen to Episode 143 of Security Now if you want to get further technical details.

How does it work?

There are different ways to authenticate on websites that support Yubikeys and you can try them with this demo. How you have to authenticate depends on the integration at the relying party: There is the possibility of using only the one time password generated by the Yubikey or combining it with a legacy login (for instance username and password). The latter can be used to achieve multifactor-authentication since the user has to have his Yubikey and also provide his password. So what is this one time password about?

A Yubico one time password

[The Yubikey is] designed to do two things: To generate the user’s unique identity and a one time pass code that only works the very second it’s used. Every time the user presses the button it generates a new pass code.

The one time password is exactly 44 characters long and consists of the user’s identity (the first twelve characters, which are always the same) and a secure token (the remaining 32 characters). This combination is used to verify the Yubikey and is inserted into the password field like any normal password. But who verifies the one time password? This leads to how to integrate…

How to integrate?

The relying party has to use the Yubico web service to verify the entered passwords. Up to now there is only this way of verifying, which means that the whole system depens on the Yubico web service being available – but the software is open source and there are server-side libraries written in Java and C that can be used to decrypt the one time password, so one could set up an independent verification service.

To ease the use of the Yubico web service, there are already client-side libraries for the most common languages out there available, which can be used by the relying parties to add Yubikey support. I used the Ruby library to integrate it into my OpenID server project which was rather easy. Those of you being familiar with Ruby on Rails might want to take a look at the Yubikey support commit to masquerade to get an impression about the details I’m going to talk about in the next paragraphs.

How to add support for Yubikeys into existing applications?

First of all you will have to let users associate their account with their Yubikey. I did this by adding an attribute “yubico_identity” to the account, which is used to map the Yubikey to the account (remember: the identity are the first twelve characters, that always stay the same). Users can associate their account with their Yubikey by entering a one time password, which gets validated by the web service. If the web service confirms, the first twelve characters get extracted from the OTP and serve as Yubikey identifier. I also added the possibility to remove the association (for instance in case your Yubikey gets lost).

The last step is to distinguish between a Yubikey and normal passwords that get entered into your login form. This is easy to, because Yubikeys are always 44 characters long and normal passwords most likely are not

So if a password with a length other than 44 characters gets entered you authenticate the user like you always did and if it is a Yubikey, you verify it against the Yubico web service (using the client-side library for your programming language). In case the web service confirms the OTP you just have to extract the identity and find the belonging account.

Technorati Tags: yubico, yubikey, security, openid, masquerade

OpenID lets users verify the ownership of an identifier – namely their OpenID URL. The protocol can also be used to exchange further data and that is what the extensions SReg (Simple Registration) and Attribute Exchange are for.

You all probably know the case where you sign up for a new service using your OpenID: You are asked to identify and in most cases to submit some extra data, like an username and your email address. These are used by the relying party (the service you signed up for) to create an account and prefill the disclosed attributes. Almost every identity provider offers the possibility to manage different personae, so that you can decide which of your information should be used to sign up with. For instance you may have two personae: One for personal use and another one with your business data.

At first, there was only SReg, which has a fixed set of nine attributes: nickname, email, gender, fullname, dob (date of birth), postcode, country, language and timezone. This offers the possibility to exchange some of the most basic user attributes, but has a major disadvantage: The set of attributes is fixed and cannot be extended, so that it is not possible to exchange the name of your home town or your website url.

This is where Attribute Exchange comes into play: AX does not give us a fixed set of properties – it is a namespace in which custom attributes and their types can be defined, as for instance the ones that are defined in AXSchema. An attribute is a combination of type identifier, title, count and value. The type identifier is an URL and defines what the property is – a street address, phone number, blog url, whatever. The title is used to inform the user about the kind of data being requested, for instance “Your ICQ number”. Count defaults to one and offers the possibility to request more than one value of the same type. The value is the data that the user/identity provider discloses.

Right now AX suffers the chicken-egg-problem: It is rarely supported by relying parties and identity providers – why request, when there is no one who responds? Same the other way round… but AXSchema lays the ground to solve this problem: Relying parties are given a set of attributes they can start to request and identity providers who already support SReg can easily migrate to support AX. Theoretically Simple Registration is deprecated, now that there is Attribute Exchange.

But there is even more to it: AX is not just about relying parties fetching user data, the specification already contains store requests, too. Attribute Exchange Store can be used by the relying parties to transfer updated data back to the identity providers. Well, this seems to be far ahead, but nevertheless it offers interesting possibilities and I will spend some time experimenting with it.

Last week I implemented the fetch part of Attribute Exchange in masquerade. It was fairly easy, as it is already supported by the ruby-openid gem and one basically just has to define some extra mappings for type identifiers to persona attributes. The only other identity provider supporting Attribute Exchange Fetch I know so far is MyOpenID. They do not support the AXSchema type identifiers, but I guess this will be fixed soon, which would be great, because MyOpenID seems to be pushing the innovation in the OpenID community.

To offer myself a sandbox in which I can test exchanging data between identity provider and relying party, I also implemented AX fetch requests for venteria. Theoretically – or practically, if your identity provider supports AXSchema – you can now update your venteria profile with your submitted persona details on every login.

I will be using Attribute Exchange extensively in my bachelor thesis, which is about identity management in academia. I will be using masquerade to setup an OpenID provider for the University of Bremen so that we can offer OpenIDs to students, who can use them to sign up for lectures or use them to verify their student status to relying parties. This is an interesting field of research and some work has already been done – for example there is an eduperson namespace defined in Shibboleth. Follow up my progress here, as I will be writing about it in the upcoming weeks

Technorati Tags: OpenID, Attribute Exchange, AX, SReg, Simple Registration

A few weeks ago I finally reached the point where I decided to release a project I’m working on as open source software. Ladies and gents, I proudly present: masquerade – an OpenID server based on Ruby on Rails.

Up to now it is pretty basic, but already handles stuff like managing various personas, trusting sites and defining release policies for your registration data. The project website contains some documentation and information on how to install your own instance of masquerade, so that you can provide some identity right away…

I installed a demo application which me and some friends are actually using as identity provider – feel free to join us, help testing and give me some feedback. The UI could surely use some sexifying and I’ve already planned to extend the feature set to include things like Attribute Exchange and other improvements. That being said: If you want to join the project contact me, fork the repository on GitHub or submit some patches

For those of you being interested: The project is build heavily around the functionality of the ruby-openid gem and its origin is the server example that ships with the gem. I’ve written a module (OpenidServerSystem) which wraps some of the library specific logic and extends the controllers. The server controller (which is the endpoint for incoming OpenID requests) combined with this module provides the main functionality.

Technorati Tags: OpenID, Ruby on Rails, masquerade, Identity Provider, Open Source

Am 7. und 8. Juni 2008 wird in Bremen das erste deutsche IdentityCamp stattfinden – ein BarCamp rund um Themen wie Identity 2.0, Single-Sign-On, Reputationsmanagement, Beziehungsmanagement, Privacy 2.0. Zentraler Hub für die Organisation und Anmeldung ist das Wiki dazu, wer ein bißchen socialen will, findet das IdentityCamp auch auf venteria.

Somit wird es endlich auch mal ein BarCamp im schönen Bremen geben und ich lerne Leute wie Carsten und Thomas auch mal persönlich kennen, welche sich neben dem bloggen zu OpenID auch mit der Initiative SpreadOpenID für das Thema stark machen.

Für mich persönlich kommt das IdentitCamp wie gerufen, den aktuell entwickle ich zusammen mit Ralph einen Rails-basierten OpenID-Server. Wie sich dieser dann im akademischen Umfeld nutzen lässt, wird im kommenden Semester das Thema meines Bachelor-Reports/Abschlußarbeit sein, so dass ich dann sicher auch einen kleinen Beitrag zu einem informativen IdentityCamp leisten kann.

Technorati Tags: IdentityCamp, BarCamp, Bremen, OpenID, Identity 2.0, Single-Sign-On, Reputationsmanagement, Privacy 2.0

Kleiner Hinweis zum Wochenende: Es gibt mittlerweile ein deutsches Blog zu OpenID, welches bisher ein paar gute Einführungsartikel beinhaltet und das in naher Zukunft sicher noch sehr wachsen wird. Ich hab es heute morgen entdeckt und bin dort über den Artikel der OpenID Verbreitung in Deutschland gestoßen, welche laut OpenID Directory recht spärlich ausfällt.

Das hat mich gleich dazu veranlasst, das OpenID Plugin für WordPress zu installieren – zehn Minuten Sache und ab heute könnt ihr euch dann auch alle schön per Identity URL anmelden um Kommentare zu posten (und für mich voten, weil das toll ist, dass ich jetzt auch enabled bin).

Technorati Tags: openid, blog, openidgermany

Mister OpenID – Simon Willison – hat wieder zugeschlagen und nach seinem How to use OpenID Screencast (kurze Einführung, ca fünf Minuten) eine ausführlichere Version rausgebracht: Das Video The Future of OpenID ist ca. 35 Minuten lang und beinhaltet eine ausführliche Einführung mit Auflistung der Vorteile und Möglichkeiten, die OpenID bietet.

Besonders interessant ist der relativ kurze Teil zur Verbindung mit Microformats, wo er auf das Potential eingeht, Freundeslisten bei verschiedenen Anbietern über eine Verbindung von Identity-URL und XFN zu importieren und zu managen. Sehr gut ist auch die Idee der Social Whitelist, über die man Dinge wie Blogspam reduzieren könnte…

Wer sich also noch nicht mit OpenID auseinandergesetzt hat, sich aber dafür interessiert, dem sei dieser sehr gut gemachte Screencast nahe gelegt. Das Thema wird noch richtig nach vorne gehen – eine schöne und relativ einfach zu implementierende Technologie, in wevent haben wir es auch schon drin

Technorati Tags: openid, screencast

OpenID ist auf dem Vormarsch, immer mehr Anwendungen unterstützen das Verfahren und wir als Nutzer können wahrscheinlich schon schneller als erwartet die Annehmlichkeiten des Single Sign-On nutzen. Eines der Probleme, welche Benutzer einer OpenID in Zukunft vielleicht haben könnten wäre der Fall, dass ein lang genutzer Identity-Provider seine Pforten schließt und man somit auch seine Identity-URL verliert.

Eine einfache Lösung dies zu umgehen sind zwei Zeilen HTML, welche man auf seiner eigenen Website einbinden und diese fortan als Identity-URL nutzen kann:

In Zeile eins gibt man die Server-URL des Identity Providers an und Zeile zwei enthält die Identity-URL, mit welcher man dort registriert ist. Nun kann man die eigene Domain – auf welcher diese Zeilen eingebunden sind – als Identity-URL nutzen und muss bei einem Wechsel des Identity-Providers lediglich die dort geltenden URLs in der eigenen Seite eintragen. Die eigene Domain als OpenID ist nebenbei auch schicker, als etwas wie mein_name.myopenid.com

Weiteres dazu findet sich in der OpenID Authentication 1.1 Spezifikation.

Technorati Tags: openid, authentication, delegate

Das Integrieren von OpenID in eine Rails-Anwendung wird einem ziemlich leicht gemacht: Wer es weniger flexibel, dafür aber umso schneller fertig haben möchte, für den eignet sich das OpenID Consumer Plugin. Wer allerdings lieber selbst wissen möchte, was wie funktioniert, der kann das OpenID Login auch in wenigen Schritten selbst implementieren.

diesen Eintrag lesen »