René Løhde (aka Rene Loehde) : Cardspace

Identity framework for .Net

renel — Thu, 10 Jul 2008 18:44:00 GMT

After a long wait and anticipation it finally arrived: “Zermatt”.

This is the long awaited framework for .Net developers that had to be a logical consequence of the Claims based Identity model and the idea of Information Cards that we at Microsoft have been a keen adopter of.

Cardspace was the first glimpse of the Microsoft initiatives that was a step towards user centrism and counter measures against phishing and phraud. This was a real eye opener on my behalf, but when I first discovered that I had to code the plumbing of my own Security Token Service (STS) to be an actual participant in the threesome of the User (Subject), Requested resource (Relying Party- RP) and Identity Provider (IDP), I was somewhat discouraged.

Today I took Zermatt for a spin for the first time. I basically ran some of the samples that come with the install. The samples have the taxonomy of “Basic”, “Intermediate” and “Advanced”. The sample titles are:

Basic:

ActiveSTSWithManagedCard
Claims Aware Web App
Claims Aware Web Service
Managed Card Issuance
Simple STS For Active Clients
Simple STS For Passive Clients

Here is a short recap on some of the wording here:

“Claims” – typically a set of name/value like attributes e.g. (FirstName/Rene, SurName/Loehde,Email/renelattmicrosoftdotcom) or (Age/30, Gender/Male).
“Active” – clients and services are able to participate in web service (SOAP/WS-* aware apps) communication and processing of tokens containing claims.
“Passive” clients - usually web browser based communication (no SOAP aware apps).
“STS” – Security Token Service (Introduced in the WS-Trust specification): A web service that supports client authentication, validation and issuing of security tokens with the required set of claims about a user/subject.
“Managed Card” – Information Card issued by a website (RP) to a user/subject requesting a specific set of verified claims from a trusted third part (Identity provider).

Intermediate:

Federation Scenario For Active Clients
Federation Scenario For Passive Clients
Identity Delegation Scenario

Advanced:

Authentication Assurance
Claims Aware AJAX App
Custom Username Card STS Host Factory
Customizing Request Security Token
Customizing Token
Extending FAM Timeout
Personal Card
SAML2 Token Issuance
Web App With Multiple SignIn Methods
WSTrustSTSHostFactory

The Authentication Assurance sample is about requesting a specific authentication scheme ("Higher" security assurance like X.509) for accessing a STS. In a national Danish context this is interesting from an OCES perspective. The STS could then be used at a Claims transformation service with the incoming X.509 certificate claim (The PID/RID) transformed into a security token with a requested set of verified claims (e.g. CPR number/ Age for PID and companyNr for RID etc.).

Another Danish - dare I say governmental issue – is the SAML2 Token Issuance. Those who read Danish will perhaps remember an article and a press release about governments using SAML 2.0 as the SSO enabler in e-Government. Zermatt provides the ability to issue SAML 2.0 tokens. This means that Zermatt could give growth to some possible interoperability scenarios with Liberty/SAML 2.0 identity frameworks.

Here follow some of my test drives – primarily the ones that include some UI.

Issuing a managed Information Card:

Information Card login:

With the Cardspace UI asking to choose the Information Card to send (not running in a virtual environment I was forced to take a cell phone snapshot :-):

Granted access to the IC guarded web site:

Zermatt comes with an ASP.Net control for Information Card login (the “Click Here” and IC logo on the second picture):

So much for the UI stuff! Really the meat and potatoes of Zermatt are the abillity to create your own STS’s and thereby architecting your Identity management in the way that makes the most sense to you and your application, without writing a lot of plumbing. So I hope to really dig into that part of Zermatt in the near future.

A better introduction to Zermatt is given by Keith Brown whose whitepaper can be downloaded here.

[Post updated July 11'th: resizing pictures...etc.]

Rerun: Cardspace and Digital Signature

renel — Wed, 15 Aug 2007 22:28:00 GMT

A lot of people (well at least two) have asked me to translate an earlier post I did in January. Thanks for engaging I really appreciate it.

Entschuldigung, aber mine deutsche sprache kunstshaften sind nicht gut und ich glaube das ich nur verwirrung macht, ob ich eine deutsch Übersetzung versucht … (I rest my case*) so let me instead try to write what the “Cardspace og Digital Signatur”-post was about in English.

Each year in January “Danish IT Society” hosts a security conference. This year a Danish government appointed CA – TDC – presented how improvements in user experience for identity management like Cardspace can add value to an existing X.509 infrastructure.

Some background: In Denmark there is a government appointed CA that issues digital certificates for citizens to use when interacting with government services. The certificate is called OCES – which is an acronym that I could translate into – Open public Certificate for Electronic Services. The digital certificate is also known as Digital Signatur – translates to Digital Signature – hence its primary usages signing email and legal documents.

There are primarily two things about Cardspace that interests TDC:

Attribute services – the issued certificate basically only holds a unique number used to identify the certificate holder. This number is used in exchange for “real” data about the certificate holder by calling a attribute service that returns a name/value pair e.g. shoe-size/43. TDC saw the Security Token Service (STS) described as a main component of a WS-Trust architecture as a generalized attribute service with all security concerns enable out-of-the-box. Their thought being: “Why continue architecting our own attribute services when a generalized idea is backed by multiple vendors and communities”
Authentication – the Achilles heel of the Identity meta-system is the authentication against the STS before a security token can be issued. Some might even argue that the removing of passwords from website authentication with Information cards is turning into a introduction of password authentication at the STS’s instead.

TDC employee Peter Lind Damkjaer came to Microsoft with proposal to start a small POC on how to use the OCES (X.509 certificate) as the authentication technology towards one or more STS attribute services

So back to the original post – Peter gave a talk called “User friendly digital identity – is it possible?” During his talk he did a demo that I had made for him. The demo shows a user trying to log into the website “Rent-a-fant” (Because an elephant was the most compelling graphics I had on my machine at the time – it was an Expression Design sample). When the user tries to log on to the “Rent-a-fant” website the Identity Providers STS will ask for a specific X.509 authentication. The Cardspace Identity selector will try to access the specific certificate – however this call is intercepted by the OSP software that will prompt the user for a specific passkey. Note – In Denmark it is mandatory for a government issued certificate to be protected by a strongly typed passkey. After the user types in the correct personal password the certificate is “released” and a security token is passed on to the relying party – “Rent-a-fant” – and the user is logged on to the website.

Peter told the audience that this was a “World premiere” of seeing Cardspace and OCES working together.

My part in this POC was to

Setup and configure a simple STS to do the right things – including setting up the right certificates at server and client. I used the Simple STS from the Cardspace community site as well as the web application with the certificates for Contoso (and other well know fictious companies). I configured the STS to be able to get the right revocation list for the OCES test certificate – kind of a drag if you are not online at demo time – otherwise you have to download the revocation list before the demo and have the STS look for the local store list to check for revocation.
Develop the relying party website (“Rent-a-fant”) – build on top of the simple reference implementation that comes with Simple STS using ASP.NET 2.0.
Produce the unique graphics for the “Rent-a-fant” information card :-) - we wanted to do a co-branded card with both the logo for the relying party - “Rent-a-fant” – and for the “protector” of the local information card – “Digital signatur” (the two nuances of green that you might be able to spot on the card, just to left of the elephant). When we did this in 2006 we had a theory that putting a “Digital Signatur/OCES” logo on the graphics of the information card containing the relying party site logo, would give end users more perception of security or at least give them the meta-information the invoking this card will eventually lead to the prompting of the OCES password dialog.

The picture shows the situation where the user has pressed the information card icon on the relying party website and a call to the STS is made, the user is choosing the “Rent-a-fant” card and is prompted for the password to the certificate.

*I have a great college that encourage me to broaden my reach each time I meet him, however I am sure he was laughing behind my back when I tried to order a meal at a German gasthaus two months ago!

Første danske site med Cardspace login

renel — Wed, 04 Apr 2007 11:17:00 GMT

Takket være Henrik Biering og Netamia’s killer app af en identitets applikation – Net-safe - er jeg i dag blevet bruger på Heste-nettet.dk. Det er mig bekendt den første ”.dk” hjemmeside, som bruger Cardspace til login. Der er tale om et managed information card – der udstedes af Net-safe på vegne af Heste-nettet.dk.

Jeg forventer i øvrigt at jeg bliver overvåget på heste-nettet.dk - fordi der er noget lusket ved en 36-årig mand, som bliver bruger på et site for piger i alderen 8-16 år. Men det er nok også hovedårsagen til at der er tale om et managed card og ikke et selvudstedt kort.

Kortet udstedes via Net-safes meta-id-protal, som også har understøttelse for SAML 2.0 SSO og bankernes NetID.

Jeg er totalt begejstreret – og det kommer fra en jyde, som ellers ikke lader sig imponere!

PS. I går fik jeg i øvrigt et tip fra en af de 3 musketerer om at han havde set Apache front-runners, WSO2, har lavet deres egen Cardspace implementering pt. kun til Linux. Still cool stuff – det begynder at gribe om sig...

Venture capital møder Identity 2.0

renel — Thu, 25 Jan 2007 15:48:00 GMT

I december var jeg - sammen med en række arkitekter fra hele verden - så heldig at høre Ray Lane fortælle om hvor venture kapital pt bliver kanaliseret hen.

Beskeden var helt klar: Hvis du vil bygge "reputation"-software - så har vi pengene!

De første leverandører er begyndt at vise produkter frem - i første omgang specielt henvendt til slutbruger - personligt "omdømme". Jeg har også fået etableret mit navn på Opinity.com og håber på at jeg kan gøre mig fortjent til et pænt omdømme.

Jeg var selvfølgelig endnu mere interesseret da en kollega henviste til at der er Cardspace support på Opinity.

Her lige et par gode råd - til de som kaster sig ud i at prøve login til Opinity via Cardspace:

Registrering: På http://www.opinity.com/ tryk på "Register" i øverste venstre hjørne

På næste side - join/sign up siden - trykkes på det "Information Card", som er nederst til venstre.

Nu følger så et trin hvor Cardspace vil starte eller hvor du bliver fortalt at du ikke har undestøttelse for Cardspace. Hvis du er på Windows Vista eller XP SP2 så kræves det at du har en browser som understøtter Cardspace - IE 7 eller seneste Firefox med plug-in (har ikke selv testet med Firefox!) til Cardspace. Derudover skal man have .Net 3.0 runtime. Hvis Cardspace starter vil der stå i cardspace dialogen noget ala "denne hjemmeside understøtter ikke Cardspace" eller "kan ikke finde Information Card til login". Tiltrods for det kan man trykke på "Send" og nu skal man så sende - i stedet for at sende - tryk i stedet på "Add" og lav dit eget personlige kort- Læg i øvrigt mærke til at Cardspace er kontekst aware - og ved at det site du skal på kun kræver fornavn, efternavn og emailadresse. Alternativt kan man - inden registrering hos Opinity gå ind i Kontrol Panel i Windows og find Windows Cardspace og lave sit eget kort- så så kan bruges når man registreres hos Opinity. Note: Der er en bug hos Opinity, som gør at de ikke er så glade for karakterer uden for traditionelt engelsk karakter sæt. Derfor kan jeg ikke hedde "René Løhde" i mit Information Card eller på Opinitys hjemmeside - men må istedet skrive "Rene Loehde" (Nej, min blog titel er ikke tilfældigt valgt - jeg har et navn, som er ubarmhjertigt i software tests). Jeg har kontaktet Opinity om denne bug, som ved registrering eller logon typisk ser ud som: "Error: SignedInfo digest (9LHTwIR7/o5YiaaB8VNt7pEj9ss=) doesn't match calculated digest (QyrmfFDDyr3jPm4+qvR8aNv3VFk=)".
Hvis man så kommer ind på siden vil man skulle lave et brugernavn, password og checkbox-bekræfte at man er enig i betingelser for brug af siden - og man er inde.

Prøv så at logge ud igen - og log så ind med Information Card og log ud ....log ind og log ud...log ind og log ud........smart, ikk'?

Den måde som Opinity har valgt at bruge brugercentrisk ID adgang og udstedelsen/mapping af "Informations kort" er blot en måde at gøre det på. Der vil komme formentlig komme mange andre eksempler at få udstedt, registrerer, mappe etc. med Cardspace og lignende teknologier. Og det kan jeg sige med ret stor sikkerhed...for jeg kender et par projekter som er i støbeskeen :-)

Cardspace og Digital Signatur

renel — Mon, 22 Jan 2007 17:19:00 GMT

For en uge siden talte Peter Damkjær fra TDC på årets IT-sikkerhedskonference arrrangeret af Dansk IT. Peters oplæg havde titlen "Brugervenlig digital identitet - er det muligt?" - i den forbindelse havde jeg lavet en demo til Peter, som viste en hjemmeside med Cardspace authentikering og hvor adgangen til Cardspace var beskyttet af den digitale signatur (OCES).
Det er min klare overbevisning at Peter havde ret da han sagde at dette var en verdenpremiere - Cardspace og OCES sammen!

Nedenfor ses et screendump fra demoen - det viser "frigivelsen" af Cardspace - Information kort - via OCES.

Nej, det er ikke et manipuleret JPEG! - Bedre opløsning på Flickr.