A little late but nevertheless I managed to publish my demos from this year's TechEd Europe 2008 in Barcelona from my session on the identity meta system applied to real world projects in Austria.
As mentioned, the experience I summarized in the session comes from a project we've been driving in Austria in the electronic health care sector as outlined in issue 16 of the architecture journal in my article.
You can download the demo applications from my session at TechEd by clicking the link below:
Also here you can download the presentation material of my session by clicking below:
Essentially in my presentation I really focused on discussing four things where in my opinion the concepts from the identity meta system vision really helped us implementing our stuff:
Coming back to the second point I outlined above. If you're working with the NET.ThirdClient, the mszcool-activeSTS and the ClaimsSuperTokenService you can try out a simple implementation of our approach for making sure that only things are published into some e-health system if the patient explicitly agrees at leat two times. The model from a business point-of-view was the following:
Subsequent graphics should outline what's going on there. Take the first graphic as an example. Here the previously defined process is executed as needed. The client authenticated for read-stuff and gets a token for reading stuff without the super-token-claim. Later during the medical treatment the doctor wants to publish stuff and therefore the patient authenticates a second time. That second authentication includes the previously issued SAML token which leads the STS to include the super-token-claim in the newly issued token. With this newly issued token the client software of the doctor can issue an update on the back end e-health service of the current context.
If one of the authentication steps, either the first or the second one is missing, the STS won't issue a token with a super-token-claim. And therefore the e-health services should and can simply deny access to any updating operation - based on a simple query whether a claim has been added to the token issued by the STS or not. The following graphic demonstrates what happens if the client tries to update content in an e-health services without the first authentication-step so that you can better understand our selected approach and idea:
The neat thing is that the e-health services really just need to query the issued SAML-token from the STS for the super-token-claim. If it's there let updates happen, if not then not;) As simple as that. In classic scenarios they would need to manage sessions, state and all that stuff what is much more complicated.
In my opinion this really shows, how claims-based security (as a part of the concepts from the identity meta system vision) really simplifies complex processes in the security world by separating the responsibility of authentication from authorization and by making authorization as simple as querying standardized tokens for claims.
If you're interested in my approach for building bridges between platforms through the separation of concerns with STS'es and relying parties, just take a look at my previous posting which I created for TechEd 2008 and the local DevCamp conference here...
Any questions - feel free asking me through comments or the contact link here of the blogging-engine;)