Identity Dialtone vs OpenID

Two recent posts of Mark Dixon about Identity Dialtone and eliminating gossipy cousin mabel metaphorically compare the Plain Old Telephone Service with Identity as a Service. Mark Dixon sais IaaS should follow the characteristics of POTS and that IaaS should be User-Centric.
I'm going a step further then Mark and I'm going to put the name OpenID on it an see if OpenID can match up with POTS and its characteristics.

• Highly available :OpenID at ISPs will provide High availability
• Highly reliable: The exisitng internet technologies (see further) are working reliable now, so will OpenID.
  
• Highly standard: OpenID is an open, decentralized, free framework. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman).
• Easily recognized: Everybody knows URLs. The OpenID-logo is easily recognizable.
• Simple to use: Login to your Identity Provider once and start using your OpenID URL
• Usable: It allows you to login easily. Just use your own URL.
• Ubiqutous: Here we have a problem.
• Critical to our daily activities: IaaS itself isn't critical yet, and this is the same for OpenID.
  
• So commonplace we take it for granted: URLs are taken for granted.

The ISP could be a good replacement for the Telecom companies as it should only distribute the URLs. There is only one (pretty important) issue regarding this and that's privacy. Should your ISP be in control of all your Digital Identities?

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).

Opensource internship

About a month ago we, me and my friend and fellow student Wouter, started our internship at IS4U. I'll keep this introduction about us brief. I will just say that we arrived on a blitz from our Erasmus in Finland just the night before we started and we're graduating as Bachelors in Applied Informatics in June.
Our task was simple, we were to combine a single sign on (SSO) system, in our case it was CAS, together with a Virtual Directory: Penrose and MyVD. All of them open source software. We, being familiar with Linux, were somewhat used to working with open source software and had a good feeling of things to come.
What we experienced with the latter- myVD - was something different. Apart from its strange suggestive name it was a struggle and sometimes a real hassle to find the correct information and descriptions for implementing some specific needs for our project. On top of that it was also very unstable. It wasn't long before we deemed this piece of open source software inadequate for what we would need it. The myVD software was not up to par, although it has some potential it certainly lacks proper documentation. Trying to configure something that has very little documentation and a small community for support is a difficult thing.
Our second confrontation with a free virtual directory, called Penrose, was a lot better. It even came with a software program to configure the entire virtual directory with the aid of wizards, clicking buttons and right clicking some options. But as I feared our enthusiasm didn’t last very long. As soon as we were done configuring we spend about double that time troubleshooting our configuration because it flawed some small, but crucial, things. Not to mention that it has some serious issues with third party LDAP browsers.

To compare the two free products would be difficult.
MyVD was small, uncomplicated but lacked many options. Penrose was bigger, mature, more complicated; it looked well documented and came with a really nice development tool, Penrose studio. But here we also have to add that this product is far from ready to be implemented in a system that has to be stable and secure. It does offer more options but it’s still not finished. We will see what happens in later releases.
All in all our experience with these products, considering they are free, are not that bad and if we had a better background of the LDAP concept we would probably have been able to figure out what we did wrong faster. But apart from that it’s safe to conclude that these free Virtual Directories, especially Penrose, probably have a future, just not right away…

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.

"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.

Server Encryption key

When you setup a development and testing environment with Sun Identity Manager, you are going to get some problems with Server Encryption Keys when you try to import encrypted objects from one server instance into the other.

Server encryption keys are symmetric, triple-DES 168-bit keys. A server can have more then one key. Every encrypted object is prefixed by the ID of the encryption server that is used. So Identity Manager knows which Server Encryption Key to use.

For the testing and development environment it's usefull to have the same encryption keys so you can exchange your encrypted objects without much effort. You can use the Manage Encryption Key feature to create new encryption keys, export them and re-encrypt the objects with the current encryption key. This feature doesn't allow you to set the current encryption key to a specific imported encryption key. So it can't help us to get the same key on both the test and development installation.

For this problem we had to make a custom workflow that invoked a custom java class. The java class just gets and sets the current Server Encryption Key. The workflow displays the current key and a drop-down-box to pick your new Current Server Encryption Key. Once you imported the new Server Encryption Key (through import exchange file) and set it to the current key, you can re-encrypt all objects with this current key through the Manage Server Key feature.
With this solution you can have the same Server Encryption Key on all your Identity Manager instances.

Roles become cards ?

I agree with Dave Kearns when he says

Good post today ("No User Context Decisions in your Enterprise?") from Pam Dingle ...

Situations #1 and #4 in Pam's post are theoretically resolved using a role based access control approach. This leads me to the following two questions:

1. Does role equal context ?
2. Do (virtual) cards become a convenient means for activating one's role ?
   

Answering my own questions, I would say "yes" for both situations.