Authentication as a Service

In partnership with Swivel Secure, the owners of PINsafe, a multifactor authentication solution inTHiNK has successfully delivered a solution to hosting PINsafe in the cloud opening the way to delivering bank grade authentication as a service at a price affordable to all.

inTHiNK has developed a fully standards based Security Token Service that sits in front of PINsafe allowing the service to engage in the exchange of SAML-based claims leveraging the core value of PINsafe’s guaranteed one-time code algorithm.

As shown in the diagram here, a trust relationship is created between a relying application, here it is an Azure hosted .NET web application, but it could exist anywhere, and the PINsafe Federation Service (the Security Token Service). On entering the application, the client is redirected to PINsafeFS where they are challenged to submit a valid username and pin  through this services relationship with PINsafe itself.The client submits a user name and one time pin code and on successful validation are redirected back to the relying application with a valid SAML ticket that can be used by the relying application.

To try it out, just visit http://pinsafe.cloudapp.net and see for yourself.

Once you hit this site you will be redirected to PINsafeFS and asked for a username and pin.

• Type in the user name test and tab to the password.
• A unique TURing string will now appear.
• Type in the characters that appear at position 1,2,3 and 4 of this string into the password field.
• Submit and you will be validated by PINsafe
• Once validated, a set of claims about the user will be wrapped in a SAML token and passed back to the relying application.
• Back on the relying application, this SAML token is unpacked and the claims are accessed which include the user name.

Simple!

PINsafeFS is now in beta and available to clients to work with. The next phase will see the delivery of a full featured self-service portal to allow relying applications to manage their identities and the claims they wish to store and use for their users.

PINsafeFS is full standards based and non-invasive using WS-* protocols and SAML tokens.

Now

Advertisement

Azure Architectural Guidance Part 1 Review: Migration

I once had the chance to move over to Redmond to deliver architectural guidance for Azure with the patterns & practices group so you can imagine my interest in seeing what they managed to produce in my absence, despite it taking quite a while to get this out there.

Where to get it

Documentation:

Source code:

The Review

As a piece of “Achitectural” guidance I am to be convinced that this delivers on its promise. In what states to be the first in a series it, rather oddly, decides to focus on “Migration” as the first topic. Personally, I was expecting more of a architectural review of the platform itself taking into account architectural considerations of reliability, scalability, redundancy and security and the like. These, instead, are confined to a rather light-weight platform overview, that raises more questions than it answers, including several inaccuracies, that reads more like marketing literature than offering technical insight. This may be because it is assumed that the “what is Azure?” discussion has already been done to death, but I don’t agree. No one has really addressed the architectural considerations of the platform, providing a thorough explanation of how features have been implemented and on what their limitations are. Certainly, nothing exists, to the level required by architects facing real business and technical opposition to cloud adoption. This, in my opinion is a missed opportunity and something that is still required.

That said, this is couched as being “guidance” and therefore the fact that it seeks to investigate the process of “migration” should not make it any the less useful. However, in this regard too, it fails to really deliver what, in my opinion the architect requires. Rather than considering a wider range of ‘adoption’ scenarios, it chooses instead, a simple, straight forward migration scenario in the context of an enterprise that has no concerns over use of cloud services. The real issues architects face in convincing others of the value of cloud, and even in convincing themselves in order to champion the opportunity is therefore avoided. A broader look at migration approaches and patterns and how these apply in the context of Azure I think would have provided more value to the architect.

However, it is important to note that the guidance is not completely devoid of any architectural value and the “How much will it cost?” section is a pretty useful evaluation approach to considering the cost impact of design decisions. It also does a reasonable job at introducing the subject of lifecycle management, although this is rather over simplified, it is still useful in highlighting the requirement. But it is on the developer side where the guidance starts excel, providing hundreds of developer gems hidden through out the document, such as the effect of partition keys on table query performance and in identifying the differences between development and windows azure table storage, referencing a useful MSDN article on the subject. In valuable stuff, but hidden from view.

In fact, it is pretty clear why the scenario was chosen, this is not really about providing architectural guidance, but in providing a context for explaining how to implement claims-based identity on Azure. As a technical resource for providing practical developer guidance on implementing a Claims-Based Identity and Access Control using Active Directory with an Azure application, this guidance actually scores pretty high. This type of guidance is simply not available else where. The problem and shame is that all this architectural veneer, hides the fact that this delivers genuine and much needed technical value and further, that no one who needs it will actually find it.

All in all, this is a valuable and well written resource, but my concern is it’s misdirected and that it’s value wont be fully recognised unless the right audience find it and in its current format, this audience would find it hard to get past the first pages to find all the goodness inside. The need here is to liberate the value and consider re-delivery as a straightforward, honest, simple to follow, developer how to guide. In the mean time, if you want to try and implement claims-based identity on Azure than I’d recommend skipping straight to Phase 1: Getting to the Cloud or even straight to the source on codeplex.

The Verdict

Rating (as Architectural Guidance): 5 out of 10. There are gems, but they’re hidden.

Rating (as Developer “How to”): 7 out of 10. If reformatted as a developer guide I’d put it nearer a 9!