Why You Should Care About Privacy

On April 4, at 10am Pacific, Oracle Identity Management (@OracleIDM) will be hosting a twitter conversation on privacy (#PrivQA). I am pleased to confirm that the Ontario Commissioner of Information & Privacy, Dr. Cavoukian will be joining the conversation. In particular, I would like to encourage privacy and security industry folks to participate. For more information, see our recent newsletter Q&A with links to her whitepaper on privacy by design (PbD).

Privacy is an issue that has been of concern to myself and many other industry professionals. Most of us continue to be amazed that for the most part, both users and the application developer community simply do not care. When the subject arises, eyes immediately shut with yawns soon to follow.

Yet, every day, more and more problems emerge in the industry that are leading to monetary and even physical harm. For example, financial fraud appears to be exploding fuelled by easy access to personal information available on social services. Fraudsters combine social demographic information to leverage weak classic communications media like fax and telephone to convince financial institutions to transfer funds (see Canadian Government Advisory on Social Fraud). In another case, access to private information in Google, apparently enabled hackers to compromise Mat Honan's Apple accounts, even remotely wiping out his laptop, iPad, and iPhone (Wired Article). Here, where I live in BC, there is the sad story of Amanda Todd, who was bullied to the point, she committed suicide. Was this a lack of privacy? Was there a lack of appropriate anonymity? Was this poor system design? We are only just beginning to understand how far reaching privacy issues can be.

These cases also show there are some interesting relationships between anonymity, privacy, and security that need further exploration. Do I need to be anonymous? I live an honest life, why do I need to keep my personal information private? Why should I care about anonymity? The system is secure right? Nobody asks who is the security intended for. What motivates the service providers? What damages do they face in the event of real losses? We are now discovering that while we may have the best of intentions, the fraudsters out there do not. Boring as the subject of privacy may seem, we should all be worried. We should all care.

Dr. Cavoukian's efforts to get our industry to start thinking about Privacy-by-Design are to be applauded. I'm not sure where this will go, but I'm glad this conversation has started. Remember to join in the twitter conversation on April 4 at 10AM (Twitter hashtag #PrivQA).

Originally posted on: Oracle IDM Blog.

Standards Corner: Tokens. Can You Bear It?

This week's post is all about tokens. What are the different types of tokens that may be used in RESTful services? How are they the same/different from browser cookies? What are access tokens, artifacts, bearer tokens, and MAC tokens?

If I asked you what are tokens used for, many of you would answer authentication. But there is a bit more to it than that. First, I'd like to point you to a post I wrote on my personal blog called "3 Parts to Authentication"

In this post, authentication is described as a process broken down into 3 parts:
1. Registration
2. Credential Presentation
3. Message Authentication

What's important here is that many often confuse the process of credential presentation with message authentication. Credential presentation is the process where a user or an HTTP client application demonstrate (with one or more factors), that the user or HTTP client application in question is the same one that was previously registered. Having successfully completed the credential presentation process, the authenticator issues a cookie or token which can be used for a period of time, as a means of message authentication -- creating a single-sign-on session.

Today's post focuses on step 3, using cookies or tokens to access web resources. In browsers, cookies are added to requests in order to allow web sites to perform message authentication -- in effect creating the effect of single-sign-on. HTTP client applications use tokens in much the same way. They pass tokens, given to them by an authorization server, in the HTTP Authorization header of requests to achieve the same thing cookies do for browsers. In the case of tokens issued by an OAuth2 Authorization server (as with Kerberos and others), we call these tokens "access tokens" because they are used to access web resources.

Broadly speaking, there are 2 categories of tokens web sites may accept: bearer tokens and proof tokens. Bearer tokens work very much like browser cookies. They can be a simple unique identifier (aka artifact), or they can be encoded strings that have meaning to the web sites they are intended for. However to the client, these cookies are just random (opaque) text strings that need to be passed to the web site in order to access a resource (message authentication). Because the client doesn't have to do anything but merely attach a bearer token to its request, bearer tokens are very simple for client developers to use. For more details on bearer tokens, check out RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage.

While bearer tokens are incredibly simple and easy to use, there is a downside. Any client that obtains a copy of the bearer token may use it. Simple possession is enough to access the web resource (hence the term bearer). So, a critical limitation of bearer tokens is they SHOULD NOT be used over plain HTTP since they can be sniffed and copied. Web sites, accepting tokens should consider whether there is a possibility that access tokens could be sniffed or otherwise shared and does that impose a risk. Because of this, the IETF OAuth Working Group is nowworking on requirements for Holder-of-Key tokens (aka proof tokens).This document describes in detail the kinds of problems that could be solved and attempts to get to a set of use case requirements for a final token specification.

Proof tokens require an HTTP client to perform some kind of calculation that shows that only it could have used the token (such as with a private key or other shared secret). In a HoK token, a client could be required to generate a request signature, and even add a counter in order to prevent play-back attacks in addition to simple proof of a client's right to use a token. An example of this is the MAC token draft. The OAuth2 Working Group is debating whether this specification should move forward or whether a simpler specification based on JSON Tokens (JWT) should be developed.

So, in many ways, tokens build on the experience industry has had for many years with browsers and single-sign-on cookies. Tokens wielded by HTTP clients accessing RESTful web resources achieve the same feature we've taken for granted with browsers. Bearer tokens are easy for most clients to use, but require secure connections when used to prevent sniffing. Proof/HoK tokens can be used to where web resources are either unprotected, or further proof of the right to use a token is needed.

Cross-posted from OracleIDM.

3 Parts to Authentication

At the IETF85 meeting in Atlanta, I ran into Phillip Hallam-Baker after a meeting on HTTP Authentication (you may recall, Phillip is one of the editors of RFC2617 - Basic and Digest Access Authentication). We were talking about how the term "authentication" is very poorly defined and means different things to different people and different service components.

Phil pointed me to a WG draft he put together as input to the HTTP Working Group - "HTTP Authentication Considerations". In section 2, he points out that authentication has several parts:

• registration, 
• credential presentation, and 
• message (aka session) authentication.

The term 'authentication' tends to cause confusion due to the fact that there are actually three separate activities that it can refer to. When Alice establishes an account at a Web site, the site may verify her email address is correct. When Alice presents her username and password, the site verifies the data and if correct issues a HTTP cookie. When Alice re-visits the same Web site to make further requests, the cookie is verified each time. Each of these verifications is a form of authentication but they are totally different in character and only the last of these is a form of authentication that is directly related to HTTP.

Attempts have been made to distinguish between these as 'initial authentication' and 're-authentication' but this also creates confusion as some people consider the first contact with the user as the 'initial' authentication and others consider that to be the start of a Web session.

I have seen a lot of confusion about the purpose of access tokens in OAuth. Some feel that there should be strong authentication with every HTTP requests. But when you look at it how Phil lays it out, it's clear that the job of message authentication is simply to maintain session state across multiple HTTP requests. It has very different requirements from credential presentation.

Phil also has some interesting commentary on some of the problems with passwords like promiscuity, recovery, phishing, and lock-in issues. Many of us have for some time been on a rant about killing the password - but Phil talks plainly about what 'passwords get right'.

This is a great read.

OAuth2: Is OAuth the End of SAML? Or a New Opportunity?

I mentioned in my year in review post that rather then spell the end of SAML, OAuth2 might in fact greatly expand SAML's adoption. Why is that?

The OAuth2 Working Group is nearing completion on the OAuth2 SAML Bearer draft which defines how SAML Bearer assertions can be used with OAuth2 essentially replacing less secure user-id and passwords with more secure federated assertions.

Before I describe how this works, here is some quick terminology:

• Resource Service - A service offering access to resources, some or all of which may be "owned" or "controlled by" users known as "Resource Owners".
• Resource Owner - An end user, who is authorizing delegated scoped access by a client to resources offered by a Resource Service
• Client - An application (e.g. mobile app, or web site) that wants to access resources on a Resource Service on behalf of a Resource Owner.
• Authorization Service - A service authorized to issue access tokens to Clients on behalf of a resource server.

While the resource service and the authorization service may be authenticated by means of TLS domain name certificate, both the client application and the end-user often need to be authenticated. In "classic" OAuth, you can use simple user-id's and passwords for both. The SAML2 Bearer draft describes how federated SAML assertions can be used instead.

A typical scenario goes much like this.

OAuth2 with SAML

1. Alice (resource owner) accesses a corporate travel booking application. 
2. In order to log into the corporate travel application, Alice is redirected to her employer's Identity Provider to obtain a SAML Authentication Assertion. 
3. Upon logging in to the Corporate Travel Application, Alice wishes to update her seat preferences with her selected airline. In order to do this, the corporate travel application goes to the authorization server for the airline. The travel application provides two SAML authentication assertions: 1) An assertion representing the identity of the client application, and 2) an assertion representing Alice. The scope requested is "readProfile seat". 
4. Upon verifying the SAML assertions and delegated authority requested, the authorization server issues an access token enabling the corporate travel application to act on behalf of Alice.
5. Upon receiving the access token, the corporate travel app is then able to access the frequent flyer account web resource by passing the token in the header of the HTTP Request. The Access token, acts as a session token that encapsulates the fact that the travel app is acting for Alice with scope read & seat update. 

This SAML Bearer flow is actually very similar to the classic OAuth 3-leg flow. However instead of redirecting the user's browser to the authorization server in the first leg, the corporate travel app works with the user's IDP to obtain a delegation (or simple authentication) assertion direct from the IDP. Instead of swapping a code in the second leg, the client app now swaps a SAML Bearer assertion for the user.

OAuth2's ability to leverage different authentication systems makes it possible for SAML to enhance OAuth2 security going even further to eliminate the propagation of dreaded user-ids and passwords in much the same way SAML did for classic federate web sign-on. Rather than making SAML redundant, OAuth2 has in fact increased SAML's utility.

Note: this post cross-posted from the OracleIDM blog.

OAuth2: How does OAuth2 Make Crypto Easier for Developers

Note: cross-posted on OracleIDM blog.

On my last blog post on Oracle IDM, Marc asks some very good questions that deserve a longer response:

Phil,

Here's where I get confused about OAuth2. I keep hearing you don't need crypto (which is often where developers get so tripped up on other federation protocols) but how do you securely have a self contained token without crypto? You mention signing a token, but isn't that crypto? If you are relying solely on transport security does that mean all connections need to be HTTPS mutual authentication to be viable?

Thanks
Marc

Let me break this up into a couple of paraphrased pieces:

1. If you do not use crypto, how do you securely have a self-contained token without crypto (aka bearer token)?

In OAuth1, the algorithm, usage and signing instructions were narrowly defined (probably limiting the life of the spec). OAuth1, assumed all communication would be insecure and therefore the access token itself needed to be secure. This required each client developer to implement the specifications MAC token in order to access services.

In contrast, OAuth2 the assumptions are reversed. Communication are secure, so tokens do not need to be self-securing (as MAC tokens were in OAuth1). OAuth2 opens the door to using simple bearer tokens (RFC 6750) to access services. OAuth2 assumes that because the issuing process is secured by TLS, the mere possession of a valid token is sufficient to authenticate or rather maintain the session relationship with the client.

With that said, there are still many scenarios where stronger ongoing authentication of the client is important to improve security. For a larger discussion on this, check out the current OAuth2 WG Security draft which discusses these issues.

2. Does this mean all connections must be HTTPS mutual authentication to be viable?

Mutual:
TLS Mutual authentication is useful, but is not required. OAuth2 allows the client application to be authenticated through other means such as client secret, a JWT, or SAML assertion. One of the problems with TLS mutual authentication is when TLS terminates before the server (e.g. in a load balancer), the server may not be able to access the client's authentication with the load balancer.

All:
Let me first qualify that not all communication needs to be secured in all cases. Let's look at the two main endpoints that are being communicated with. The Authorization Server (aka Token Server), does require that at least server-authenticated TLS be enabled for all communication. In the case of a Resource Server, server-authenticated TLS is not required but SHOULD be used when using tokens without crypto (aka bearer tokens).

Thanks for the questions. Please keep them coming!

Is OAuth2 Ready for Use?

In what seems to be becoming a regular thing, I have another blog post on the Oracle IDM blog, "Standards Corner: A Look at OAuth2", where I answer some tough questions:

• What is the difference between OAuth1 and OAuth2?
• Is OAuth2 mature enough to use?
• Should customers deploy OAuth1?
• What's happening with OAuth2?

No Time To REST For The Holidays

I was invited to sum up 2012 and make my predictions for 2013 on the Oracle IDM blog. Check out my post here covering:

• Emergence of REST-based Cloud
• Fat Apps are now Phat!
• Web 3 Drives Forward a New Authorization Model: OAuth2
• Is SAML Dead or Just Starting?
• Provisioning to the Cloud
• Looking Forward - The Emergence of the Identity Cloud and the Interop Language

OAuth2 Threat Model is now RFC 6819

OAuth2 has proven to be a broadly successful tool for authorizing access to web resources from a variety of browser and non-browser web clients. With such wide applicability came an incredibly broad set of security scenarios that OAuth2 needed to cover. It is testimony to the working group that this was achievable while maintaining the simplicity of the original OAuth specification.

The contents of this specification originally formed the security considerations for RFC 6749, but after some good working group discussion the working group decided to break the considerations in two parts: RFC6749 would contain considerations of interest to implementers, while the Threat Model would be of broader interest to deployers. That document is now published as RFC 6819.

I and my fellow co-editors would like to thank the members of the working group and the extended IETF community for their efforts in capturing this valuable knowledge.

SCIM - What Should A New SCIM WG Address?

In my last blog post, I mentioned that SCIM 1.0 defines as a simple provisioning API for cloud application service providers. SCIM is architecturally oriented as a connector API specification in a hub and spoke architecture typically with an enterprise provisioning system at the hub and a cloud application service provider being a spoke. Other variations could include provisioning for on-premsise SaaS applications as well as directory synchronization. For each cloud application, the enterprise IDM hub should be able to just invoke the SCIM RESTful API of a target application's SCIM provisioning end-point.

But is SCIM about to repeat much of the history of SPML? Has it corrected some miss-steps? Yes, definitely. Is that enough? Let's look at some of the historical issues that will be of relevance to the evolution of SCIM. Just to be clear, my comments are not to suggest that SCIM adopt SPML features. My comments are intended so that SCIM learn from SPML's history.

The Value Problem

SPML 1 was very much like SCIM 1.0 is now. A simple API that supported basic CRUD operations. When SPML 1 was developed, the proposed value proposition was that provisioning would be made easier if applications would adopt a standard IDM protocol, then provisioning of enterprise applications would become easier. The value to application developers was that simpler, standardized management API would not be specific to individual IDM vendors and could inter-operate with any IDM provisioning product.

From the enterprise perspective SPML 1 made a lot of sense since it would make all applications provision the same way. They could pick and choose the IDM product they wanted to use. More importantly, enterprises would not have to pay for custom coding when attempting to provision to proprietary APIs of applications.

SPML 1 was somewhat successful, but before it could be broadly adopted, several new requirements emerged and SPML 2 was defined (though SPML 1 remains dominant).  SPML 2 introduced many new features such as

• the clean separation of payload from protocol; 
• the introduction of new common IDM operations (e.g. password operations);
• a formalized DSML/XSD profile;
• targeting - the ability to provision accounts through a gateway; and,
• an extension mechanism for registering capabilities so that contributed capabilities could be made inter-operable.

Yet application vendors wanted more: they wanted standard schema conventions, they wanted a standard that enabled them not to have to introduce individual IDM vendor dependencies. If they could write one SPML provider once and be done with it, their costs would go down.

Many idM vendors were concerned that SPMLv2 had gone too far. In the end, it was either perceived complexity or the basic value proposition was not enough for SPML to succeed.

Has SCIM moved the ball forwards? On one important point, the answer is yes. SCIM has put forward a well defined schema with clear definition of attributes and their use or meaning. The RESTful style of SCIM keeps schema cleanly separated.

The Information Semantics Fidelity Trade-off

IDM Provisioning product developers have always faced an engineering trade-off. Would a standardized provisioning protocol/API lower development costs? Each application is unique, therefore each unique application APIs often has highly specific semantics and contextual meanings. While saving money initially by using a standardized SCIM or SPML API, does this mean a loss of "fidelity" or functionality? Do different systems treat the notion of person or user in the same way? What does delete person mean? In translating information semantics, is mapping intelligence in the hub or in the spoke or somewhere in-between? The engineering question is: should the provisioning system understand the true nature of the application, or should the application understand provisioning systems and behave like an identity store? In my experience, there's no clear answer. It depends on the nature of the application.

Does SCIM help in this regard? That is yet to be determined. The SCIM community will need to discuss issues like how to handle high level IDM operations like suspend vs. delete, password resets, federation and other deeply IDM specific issues and how they are operationally mated with a diverse application services API community.

The Gateway Problem

Corporations that are organized into divisions often end up with different independent IT organizations and outsourced providers -- especially after corporate re-organizations, acquisitions, and divestitures. In these cases, single-hub provisioning systems often become unpractical. While some may view this as rare situation, the whole idea of a cloud based apps hosted externally makes this situation de rigueur.

In these cases a key provisioning architecture element is the ability to support provisioning gateways and hub-to-hub provisioning. Gateways (or proxies) serve a dual purpose of both firewalling direct access to internal services and they serve to greatly simplify network complexity for inter-organization communication. As well as solving basic firewalling issues, gateways can also support mapping functions changing from a standardized provisioning protocol like SCIM into application specific connector protocols like CRM OnDemand who may or may not have built support for a protocol such as SCIM.

Since a gateway acts as a "proxy" to other connected SaaS services, SCIM needs the ability route or "target" operations to specific application end-points. SPML 2.0 and now RESTpml/SIMPLEST supports targeting. Targeting enables a provisioning "hub" to indicate to a provisioning "gateway" that particular person requires an account in a particular target system. In the diagram above, Alice, employee 1234 is to be provisioned into the "Finance" application.

SCIM with routing/targeting becomes a critical communication protocol for hub-to-hub and hub-to-gateway provisioning. Unlike SPML implementation of the past, inter-operability becomes a key requirement because in the world of cloud provisioning it is more likely that gateway and hub implementations will come from different provisioning product developers.

The Cloud Does Change Everything

SPML was built for a world where everything occurred inside an enterprise. But the requirements for cloud identity management are substantially different. Cloud based provisioning architecture must take into account:

• Performance and Scalability – A lightweight HTTP protocol such as with REST/JSON is a cornerstone requirement when provision cloud environments with 100s of millions of users.
• Firewall requirements – securely connecting directly to application APIs (standardized or not) will likely require some special sauce. It's not reasonable to expect all application end-points to be able to support this in the cloud.
• Cloud Providers are often "hubs" themselves – since cloud providers offer more than one application service, cloud providers may behave more like "hubs" than spokes.
• Cloud Providers With Value-Added Data – some cloud providers may have provisioning and identity management systems of their own. This suggests that cloud hubs may need to flow back to the enterprise.
• Entitlement Reporting – A big requirement for provisioning these days with SOX is the need for entitlement reporting. Further, when you are paying an external cloud provider for services rendered, you want to make sure you are paying for the correct employees to use cloud services. A key component of provisioning systems need to report back available rights of all users from all applications, especially through cloud "hubs".
• Inter-operability – no longer can we assume hubs and gateways are provided by a single vendor. Cloud-based provisioning will almost always be multi-vendor based.

What Should The New SCIM WG Address?

The main success of SCIM has been a standardized schema. It defines the attributes and says what each means -- something that application vendors always wanted. This is goodness. Yet, there are some gaps when you start to consider the overall provisioning system that will emerge from SCIM's adoption.

A couple of scope items that the future IETF SCIM WG should be considering:

• Routing or targeting – SCIM needs to have a way to handle updates through gateways and hub-to-hub relationships for supporting multi-service cloud providers.
• Persons as distinct from Users – Currently SCIM combines these entities together in a simple form. The reality is that in the hub, persons hold multiple user accounts. Is a change needed to SCIM schema to support managing the relationships between persons and their user accounts? This may not need change, but wider discussion is needed.
• Peer relationships – Cloud providers with hubs may need to be able to flow updates back to client hubs.
• Reporting – attestation is a key component of provisioning. Not only will clients want to be able to reconcile what cloud providers are charging for, but clients also still have requirements driven by Sarbanes-Oxley. SPML's approach was burdensome. Could SCIM support the ability for a client "hub" to get the information it needs to accomplish this in a lightweight way in the spirit of SCIM?

In my next post, I'll have more details on how I think the routing issue could be addressed.

....With thanks to Gary Cole and Mark Diodati for their wisdom and input.


Note well: the comments posted here are my personal comments and are intended as input to the IETF and are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).

Simple Cloud Identity Management - Getting Started

Good news! The folks behind SCIM have decided to begin the process to formalize SCIM at the IETF. To kick things off, there will be a birds-of-a-feather session planned for the upcoming IETF meeting in Paris at the end of the month.

The above diagram shows the typical scenario that SCIM attempts to solve. The perspective of SCIM is to provide a common RESTful API for cloud SaaS providers that enterprises could use to provision accounts. Instead of an enterprise having to provision users to many cloud providers using many different APIs, SCIM proposes a simple provisioning API that all application service providers could support.

SCIM's deployment architecture model is a simple hub-and-spoke model where the enterprise IDM system is at the "hub" and each cloud service provider is a spoke. The idea behind SCIM is that each spoke is enabled by a standardized 'connector' using a standardized SCIM RESTful API.  Without SCIM, the alternative is that enterprise provisioning systems have to support many different proprietary service APIs.

So far, I'm impressed with SCIM. It does the job it was designed for. But it does it solve all the requirements for cloud provisioning? I'll get into that in my next blog post.

For more information, check out the SCIM mailing list at IETF.