Monday, May 28, 2012
Friday, May 25, 2012
Thursday, May 10, 2012
Over simplified graphical representation of OpenID Connect
The OAuth 2.0 authz code grant type defines how to use the browser to get an access token (blue) from the AS to the Client. The OAuth bearer spec defines how to then use that token on API calls to arbitrary endpoints.
OpenID Connect layers new pieces on top - the new ID_token and the UserInfo endpoint (both in orange). As before, the client (normally) leverages the browser as the means to obtain tokens.
The Client consumes the ID_token and creates a session based on it. The Client uses the access token to call both the UserInfo and other API endpoints.
Wednesday, May 02, 2012
Paul Madsen continues with Ping Identity’s Office of the CTO
Identity Management Expert Paul Madsen continues with Ping Identity’s Office of the CTO
Respected Identity Advocate to Help Develop and Evangelize Next Generation of Standards Including OpenID Connect and OAuth
Ping Identity®,
The Cloud Identity Security Leader™, today announced that Paul Madsen
will remain in the company’s Office of the CTO as senior technical
architect. In this role, he will continue to develop and evangelize the
next generation of identity standards include OpenID Connect and OAuth.
“An
active and well-respected member of the Identity community, Paul brings
an in-depth understanding of interoperability and open standards to our
team,” said Patrick Harding, CTO of Ping Identity. “This expertise
directly aligns with Ping Identity’s standards-based approach to solving
complex identity management challenges and makes him a natural fit for
our expanding team.”
Thursday, April 26, 2012
A taxonomy of confusion
Axel Nennker pointed out on Twitter an OpenID implementation between Amazon & MyHabit.com.
A screenshot of the login page
A screenshot of the login page
My first reaction was that this was an example of the password
anti-pattern, ie the user is being asked by MyHabit.com to present their
Amazon credentials.
Axel pointed out to me that this was actually an Amazon page and not a MyHabit page, but branded to look like a MyHabit page - in Axel's words
So it's not password anti-pattern, because MyHabit never sees the user's credentials.
But it is, to my mind, misleading, because the MyHabit branded login page may make it feel to a user like they are presenting their Amazon password to MyHabit.
It's not password anti-pattern, its the 'anti password anti-pattern'.
A taxonomy is called for
Saturday, April 21, 2012
Thursday, April 19, 2012
Wednesday, March 21, 2012
Holy sh&t, this stuff is real
Logged into my Ping WebEx on Android without presenting my Ping credential to anybody but Ping.
Screenshots follow
Instead of authenticating directly to the client, I select 'Sign in through your corporate website'
I knew this from URLs
I'm in. Now I can avoid meetings with @weeunquietmind even when mobile!!
Screenshots follow
Instead of authenticating directly to the client, I select 'Sign in through your corporate website'
I knew this from URLs
I even got my first password attempt wrong - this is no cardboard demo!!
I'm in. Now I can avoid meetings with @weeunquietmind even when mobile!!
Wednesday, March 07, 2012
Authentication options for mobile native email apps
Update: Travis Spencer pointed out that the model I describe below as 'horrible', where the email app collects the enterprise password and uses it on each IMAP call, has advantages - key of which are that it creates no new password and can work with existing email clients. I defend my disgust due to the undesirability of storing the enterprise password on the device
----------------------------------------------
Inspired by a customer conversation, and mindful that (most but sadly not all of) my Ping colleagues take great enjoyment from my taxonomizing, I describe here the different permutations by which an enterprise employee can be authenticated when using a native mobile application client of a SaaS email provider (instead of a browser interface).
Note: although presented in the context of email, the various permutations are relevant to any native SaaS application.
The different options can be characterized by
- Which entity issued (and will subsequently validate) the password used for authenticating the employee –the enterprise or the email provider
- How that password is used, ie where does the employee type it in – an enterprise login page, an email provider login page, or the native email application
The resulting combinations have very different security characteristics, discussed below.
Enterprise password presented to enterprise login page
This is the ideal from a security PoV – the employee continues to use only their existing enterprise password, and presents that password only to the enterprise itself. Additionally, if the authentication happens at the enterprise, then stronger authentication than password is possible.
But if the actual authentication happens at the enterprise, then necessarily the fact of that needs to be communicated to the email provider – this requirement satisfied by SAML SSO.
The scenario is show below
The interaction between the email application on the phone and the email provider is shown as happening via OAuth. Strictly speaking (and especially if the email provider builds their own native app) this is not necessary.
The above presumes that the IMAP exchange between the email app and the email provider is authenticated by OAuth tokens, rather than passwords (the current reality). Google led some work in 2010 defining just such a binding but it’s not clear if that has progressed.
This scenario is attractive because
1. The employee has no new email-specific password to remember
2. The employee presents their enterprise password only to the enterprise
Note that the SAML SSO step need happen only infrequently (based on enterprise policy) because the token(s) issued down to the native email client can have a long lifetime. One consequence of long-lived tokens is that, should the enterprise wish to cut off acccess to the employee’s email, they must actively reach out and delete the corresponding account at the email provider – using SCIM or equivalent.
Enterprise password presented to SaaS login page
Instead of relying on SAML SSO as the means of authenticating the employee to the email provider, the email provider could collect the employee’s enterprise credential itself, and then validate that password with the enterprise.
This is shown below
While the employee need not remember a new password specific to email, the email provider will know the employee’s enterprise password, and could misuse it if so inclined.
Enterprise password presented to email app
The above scenario had the employee present their enterprise password to the email provider in a web page (with attendant security issues). Even worse is to have the employee present their enterprise password directly to the email application – this then validated back at the enterprise.
This scenario is shown below
While this scenario leverages the existing enterprise password, it does so at the cost of having the employee share it with the email application – setting a possible precedent in the employee’s mind that could be leveraged in a phish.
A variant of the above would have the email app store the enterprise password, and use that on the IMAP calls, rather than a token issued off the password. As for above, the email provider would validate that password at the enterprise. This scenario is to horrible to even contemplate and I’ll not mention it again.
Email password presented to enterprise login page
Any taxonomy inevitably has some nonsensical corners and this scenario is one such – as it implies the employee be issued an email provider specific password, but present it to their enterprise for subsequent validation at the email provider. Which is crazy.
Let’s move on.
SaaS password presented to SaaS login page
This scenario is shown below
The above of course implies that the employee be issued (and must remember) a new password specific to the email provider.
SCIM supports the provisioning call by which the enterprise would manage the password at the email provider.
As before, the above presumes that IMAP has been tokenized, ie OAuth tokens (or equivalent) can be used in pace of the email password itself.
Revocation would require the enterprise actively delete the email provider account (or equivalent, change the password) with a SCIM delete user call (or proprietary equivalent).
Email password presented to email app
If, instead of presenting the email specific password to the email provider in a login page, the employee presented the password directly to the email app, we end up to the scenario shown below
As for the previous scenario, the enterprise pushes a password over to the email provider in an a priori provisioning step.
Although the employee will have a new password, it’s likely that they would initially provide it to the email app and never see it again. Once exchanged for a token(s), the email application would not store the password (or hopefully wouldn’t).
A variant of the above would have the email application present the password on each and every call to the email provider to retrieve mail, rather than an equivalent token.
While far from ideal, this scenario is the current reality. This is, for instance, how Ping employees access Gmail using 3rd party email apps (like Thunderbird on Android). Google’s own GMail app supports a model more like the first.
Summary
The above is summarized graphically as
where the colour-coding represents (my) assessment of how optimal the authentication model is – green being good, red bad, and orange in the middle.
Tuesday, March 06, 2012
In BYOD We Trust?
Brian Katz argues that, if you are focused on protecting enterprise data rather than the devices that that that data might be sitting on, then BYOD isn't such a big deal - because the device itself fades into the background and so whether the employee bought it or the enterprise did doesn't matter.Feels similar to the enterprise not stipulating that employees MUST install a home security alarm system if they are bringing corporate data home on weekends.
Things are alot simpler with a shift in focus to the data rather than the device. Here's my list of security requirements
- Ensure that mobile apps can access only enterprise data appropriate to the employee using it
- Protect data in transit
- Protect data at rest
- Delete data when necessary
(Of course, 'not allowing apps to store data on the device' probably means tinkering with the binary.....)
#2 is easy.
#1 implies that the app, in requesting data from enterprise or cloud servers, can somehow indicate to the server the employee in question. More and more, OAuth 2 is the default choice for achieving this. The native application gets an OAuth token that reflects the employee's identity & roles, and presents that token on a RESTful API call to get data.
Consequently, #1 is really about ensuring that
- the application can securely obtain a token that reflects the employee's identity
- the API can make the right authorization decision when it sees that token included on API calls
Wednesday, February 22, 2012
Friday, February 17, 2012
Thursday, February 16, 2012
Tuesday, February 14, 2012
Monday, February 13, 2012
Saturday, February 11, 2012
Tuesday, February 07, 2012
Sunday, January 29, 2012
Friday, January 27, 2012
Thursday, January 26, 2012
Tuesday, January 17, 2012
Saturday, December 24, 2011
Friday, December 23, 2011
Thursday, December 22, 2011
Wednesday, December 21, 2011
Tuesday, December 20, 2011
Monday, December 19, 2011
Friday, December 16, 2011
Wednesday, December 14, 2011
Monday, December 12, 2011
Callback security in mobile OAuth 2.0
OAuth 2.0 defines how mobile native applications can obtain an access token from an Authorization Server – this token used on calls to the API behind which sits the application data (e.g. their calendar, their TripIt data , etc) that the native application seeks.
Obtaining the first access token typically happens via the browser – the sequence
1) The user indicates they wish to ‘authorize the app’ or equivalent
2) the native application pops an external browser window and loads the AS login page
3) the User logs into the AS (and may be asked for their consent for that native application to be able to access particular resources)
4) if successful, the AS redirects the browser to a specified callback URL, including in the redirect URL an ‘authorization code’
5) The browserpasses the authorization code to the native application
6) The native application sends the authorization code back to the AS, and is returned the desired access token (as well as optionally a refresh token, which the native application can use going forward to get new access tokens)
Step 5 in the above might have caused you to wonder just how exactly does the browser, after grabbing the code from the callback URL, pass it to the native application?
Good question.
One emerging best practice is to leverage the mobile OSes (Android & iOS at least) support for custom schemes as a means of inter-application messaging. When the native application is installed, it registers itself as the handler for URLs of a particular scheme (just like the browser handles HTTP URLs, and the markets have their corresponding schemes).
Below is the Android manifest for an app registering itself as the handler for the 'coolmobileapp' scheme.
Once registered as a handler for a given scheme, whenever the OS sees a URL in that scheme, it will pass that URL to the application.
If then, the callback URL that the AS redirects the browser to belongs to a scheme that the relevant native application ‘owns’, then the browser, upon seeing that URL, will pass it onto the OS for appropriate forwarding to the app.
Once the native application is passed the URL, it can grab the authorization code, and use it to obtain the desired tokens.
The hitch in the above mechanism is that nothing prevents multiple native applications from registering themselves as the handler for a given URL scheme. If you have multiple browsers installed on your phone you will have seen how Android deals with multiple such handlers – it asks the user which to use for a given URL (unless a default is set). Nothing in the OS prevents such collisions, nor mediate conflicts other than this user query mechanism.
Consequently, it is theoretically possible for a rogue application to lay claim to the very same custom scheme handler as a valid native app with the hope that it would obtain the authorization code as part of the OAuth authorization process rather than the valid & appropriate app.
In the next installment, I will present ideas as to how to mitigate the above callback attack - based on discussions with my Ping colleagues Scott Tomilson, Travis Spencer, and Brian Campbell (to be fair, Brian has contributed very little).
Obtaining the first access token typically happens via the browser – the sequence
1) The user indicates they wish to ‘authorize the app’ or equivalent
2) the native application pops an external browser window and loads the AS login page
3) the User logs into the AS (and may be asked for their consent for that native application to be able to access particular resources)
4) if successful, the AS redirects the browser to a specified callback URL, including in the redirect URL an ‘authorization code’
5) The browserpasses the authorization code to the native application
6) The native application sends the authorization code back to the AS, and is returned the desired access token (as well as optionally a refresh token, which the native application can use going forward to get new access tokens)
Step 5 in the above might have caused you to wonder just how exactly does the browser, after grabbing the code from the callback URL, pass it to the native application?
Good question.
One emerging best practice is to leverage the mobile OSes (Android & iOS at least) support for custom schemes as a means of inter-application messaging. When the native application is installed, it registers itself as the handler for URLs of a particular scheme (just like the browser handles HTTP URLs, and the markets have their corresponding schemes).
Below is the Android manifest for an app registering itself as the handler for the 'coolmobileapp' scheme.
<activity android:name=".AppActivity" android:label="@string/app_name">
<intent-filter>
<data android:scheme="coolmobileapp" android:host="cma.ex.com" />
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
Once registered as a handler for a given scheme, whenever the OS sees a URL in that scheme, it will pass that URL to the application.
If then, the callback URL that the AS redirects the browser to belongs to a scheme that the relevant native application ‘owns’, then the browser, upon seeing that URL, will pass it onto the OS for appropriate forwarding to the app.
Once the native application is passed the URL, it can grab the authorization code, and use it to obtain the desired tokens.
The hitch in the above mechanism is that nothing prevents multiple native applications from registering themselves as the handler for a given URL scheme. If you have multiple browsers installed on your phone you will have seen how Android deals with multiple such handlers – it asks the user which to use for a given URL (unless a default is set). Nothing in the OS prevents such collisions, nor mediate conflicts other than this user query mechanism.
Consequently, it is theoretically possible for a rogue application to lay claim to the very same custom scheme handler as a valid native app with the hope that it would obtain the authorization code as part of the OAuth authorization process rather than the valid & appropriate app.
In the next installment, I will present ideas as to how to mitigate the above callback attack - based on discussions with my Ping colleagues Scott Tomilson, Travis Spencer, and Brian Campbell (to be fair, Brian has contributed very little).
Tuesday, December 06, 2011
Monday, December 05, 2011
Saturday, December 03, 2011
Subscribe to:
Posts (Atom)