{"id":1630,"date":"2013-03-04T22:18:57","date_gmt":"2013-03-05T07:18:57","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/?p=1630"},"modified":"2013-03-06T23:00:58","modified_gmt":"2013-03-07T08:00:58","slug":"want-multi-factor-authentication-when-accessing-web-services-try-aal-and-aad","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2013\/03\/04\/want-multi-factor-authentication-when-accessing-web-services-try-aal-and-aad\/","title":{"rendered":"Want Multi-Factor Authentication When Accessing Web Services? Try AAL and AAD"},"content":{"rendered":"

Ah, what a day! The news on the Windows Azure AD features in the Windows Azure portal <\/a>were on fire today \"Smile\" if you missed them, check this out<\/a> before going any further.<\/p>\n

The phone-based multifactor authentication preview<\/a> is probably my favorite new feature. For details, check out this walkthrough<\/a>; but in a nutshell,\u00a0 this new feature allows you to get selected users to authenticate with the directory by using both classic username\/password AND exchange security codes via SMS messages (or voice call) from their registered phones. I love it because of its simplicity, especially if compared with more traditional methods like smartcards or hard tokens. That allows slipping this extra check in the Web authentication flow very easily, technically it\u2019s mostly another redirect.<\/p>\n

Unfortunately, adding another authentication factor to Web services-based solutions is not as easy: that usually entails redeploying the clients, given that the logic for prompting the user for the extra factors, and actually pumping the results on the wire according to the characteristics of the method of choice. Right? RIGHT?<\/p>\n

Ehmmm\u2026 no. Or, at the very least, not necessarily! \"Smile\"<\/p>\n

Almost one year ago I wrote a long post<\/a> (surprised?) on the benefits of introducing a browser surface in the context of\u00a0 rich client authentication flows: luckily you don\u2019t have to read it all \u2013 the \u201cGeneral Idea\u201d section<\/a> holds the relevant info. In fact, I can summarize the entire thing in one sentence: if you rely on a browser window for driving the authentication from the server side, you can enjoy in a rich client the exact same benefits you get when authenticating with a Web site<\/em>. Including NOT having to roll out a new client when adding extra authentication logic.
\nSounds too good to be true? I can prove that last assertion, by walking you through a very real scenario.<\/p>\n

Remember the ASP.NET Tool for Windows Azure AD<\/a>? It is a rich client (its UI lives within VS itself) which performs authenticated calls (to the Graph API, to create a ServicePrincipal for the app it is configuring) secured against AAD (via AAL<\/a>).
\nAs mentioned, yesterday AAD added the ability of enforcing multi-factor authentication. In a traditional Web services client world, the ASP.NET Tool for Windows Azure AD would NOT be able to take advantage of the new authentication flow: not without a redeploy of the client, or at the very least of the authentication libraries it uses.<\/p>\n

Well, guess what. AAL <\/a>does use a browser based flow to acquire from AAD the token it needs for calling the Graph. In yesterday\u2019s walkthrough I added to my test tenant an admin which requires the new multi-factor authentication. Why don\u2019t we try to use the ASP.NET Tool with that admin user, to put to test my theory that I\u2019ll be able to use the new auth flow with old bits.<\/p>\n

You know the drill: select the project, go in the Tools menu and choose Enable Windows Azure Authentication; then enter the test tenant domain.<\/p>\n

\"image\"<\/a><\/p>\n

AAL <\/a>will display the usual authentication dialog. You\u2019ll get prompted for the credentials of an administrator, the usual username and password\u2026<\/p>\n

\"image\"<\/a><\/p>\n

\u2026but if the user you entered is one for which you assigned the multi-factor authentication requirement, your authentication experience won\u2019t be over yet. The AAL <\/a>authentication dialog will show the following\u2026<\/p>\n

\"image\"<\/a><\/p>\n

\u2026and your phone will buzz with a message. Reply back with your code\u2026<\/p>\n

\"WP_20130304_002\"<\/a><\/p>\n

\u2026and the authentication dialog will finally close. After a brief wait, the tool will inform you that the app configuration took place successfully.<\/p>\n

\"image\"<\/a><\/p>\n

That means that the tool successfully called the Graph, which in turn means that it successfully got a token from AAL<\/a>.<\/p>\n

In summary. I just used old bits to take advantage of a new authentication flow – and a multi-factor one nonetheless. Q.E.D.!<\/strong><\/span><\/p>\n

You know, I didn\u2019t really *need* to see this happening to know that AAL\u2019s <\/a>approach supported arbitrary server-driven auth, new authentication factors that weren\u2019t even considered at the library\u2019s inception, and so on; that\u2019s why we designed it the way it is. But still\u2026 having the chance to see that playing out exactly, I don\u2019t know\u2026\u00a0 it just makes me happy \"Smile\"<\/p>\n

Remember, both AAL <\/a>and the phone based multifactor authentication are still in preview: don\u2019t miss the chance to give feedback!<\/p>\n","protected":false},"excerpt":{"rendered":"

Ah, what a day! The news on the Windows Azure AD features in the Windows Azure portal were on fire today if you missed them, check this out before going any further. The phone-based multifactor authentication preview is probably my favorite new feature. For details, check out this walkthrough; but in a nutshell,\u00a0…<\/p>\n","protected":false},"author":1,"featured_media":1627,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1630","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/1630","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=1630"}],"version-history":[{"count":3,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/1630\/revisions"}],"predecessor-version":[{"id":1631,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/1630\/revisions\/1631"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media\/1627"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=1630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=1630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=1630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}