Tuesday, 3 June 2008

Unity in multiple EU eIDs

On itprofessional.be [Dutch] I read an article about a European project to link the systems of all the member states of the EU. The result of this project will be that every citizin of a European country can use his/her eID for eGovernment solutions of a specific European country. The project is called Secure Identity Across Borders Linked and it's created by a consortium of 13 member states and Iceland.

Europe doens't want to force a unified system of eIDs but instead wants an extra layer for this to happen. The first thing that popped into my head was: Federation.

Federation can be the(and I think is the best) solution to this problem. This because it doesn't matter for the Service Provider how the authentication is done by the Identity Provider.
For example, if I would want to make use of and eGov application in the Netherlands, they could use Federation to find my Identity Provider. In my case this would be Belgium. The Netherlands redirects me to the login page of the Identity Provider Belgium. Here I can login with my eID. When the login is succesful I will be redirected back to the eGov application at the Netherlands with an assertion that I'm Stefan and I'm an authenticated Belgian :). Because of the trust relation between the member states of the EU (including Belgium and the Netherlands) the Netherlands will trust this assertion and threat me as an authenticated user.

If they choose for federation then only the eGov applications need to be aware of (some of the) federation protocols. Every member state can use it's own eID login mechanism for authentication and just redirect every other user to his corresponding country (identity provider).

Labels:

Wednesday, 28 May 2008

New CAPTCHA technology already obsolete?

Discussing the latest CAPTCHA technology with a co-worker, I got the idea that CAPTCHA's are already an obsolete technology. It's successor ? Federation.

People still need to 'register' face-to-face with lots of potential identity providers. To name a few: a technician of the ISP needs to come to your home for installing an internet connection, you have to fill out some forms and hand over a copy of your identity card for opening a bank account and you have to present yourself to a clerk at city hall in order to receive an identity card. These forms of registration at Identity Providers don't require online forms, they require some sort of paper contract and a meeting in person. Some of them even hand out strong credentials in the process like tokens or smart cards.

I'm forseeing some troubles in achieving the following prerequisites but given ubiquitous trust in such identity providers and the privacy protection mechanisms enabled in federation protocol implementations, users will never have to fill out an online registration form again. Sites will no longer have to implement them or tinker with spam bot protection mechanisms, like CAPTCHA's, no more. We will have achieved the federation nirwana.

Labels:

Friday, 4 April 2008

"Dynamic" SAML

In an article at http://www.computer.org Patrick Harding, Leif Johansson, and Nate Klingenstein talk about a way to reduce the time to deploy SAML-based projects.
Dynamic SAML reduces this time through the exchange of configuration information via the metadata:
Dynamic SAML takes advantage of security best practices and the exchange of configuration information to minimize the manual steps that administrators must currently perform to configure SAML connections securely. Although it isn’t yet possible to completely automate a decision of human trust, dynamic SAML can automate the underlying exchanges to make this decision fast, simple, and secure.
Dynamic SAML simplifies the trust establishment between two partners because it allows you to send your keys used to sign and validate SAML SSO messages with the metadata:
Dynamic SAML prescribes that the partner keys used to sign and validate SAML SSO messages are included in the SAML metadata document. Trust in these keys is derived from the established trust in the metadata document itself. In effect, dynamic SAML moves trust management from a runtime issue (applicable to each protocol message) to a configuration-time issue (applicable to the overall metadata document).
Dynamic SAML is also automating the metadata exchange so that partners can retrieve the metadata when needed.

Dynamic SAML handles about the Metadata exchange and how this can help to reduce deployment times. The time reduced from creating partner connections is really signifcant and will absolutely help reducing the overal time.

Source: Patrick Harding, Leif Johansson, and Nate Klingenstein, "Dynamic Security Assertion Markup Language: Simplifying Single Sign-On, " IEEE Security & Privacy, vol. 6, no. 2, March/April 2008, pp. 83-85.

Labels: , ,