This article was originally posted on the Oracle Fusion Blog, Feb 24, 2015.Last week, I had a question about SCIM's (System for Cross-domain Identity Management) approach to schema. How does the working group recommend handling message validation? Doesn't SCIM have a formal schema?
To be able to answer that question, I realized that the question was about a different style of schema than SCIM
On Wednesday night, I watched NBC’s interview of Edward Snowden. The past year has been tumultuous one in the IT security industry. There has been some amazing revelations about the activities of governments around the world; and, we have had several instances of major security bugs in key security libraries: Apple's ‘gotofail’ bug the OpenSSL Heartbleed bug, not to mention Java’s zero day bug,
Basic Authentication (part of RFC2617) was developed along with HTTP1.1 (RFC2616) when the web was relatively new. This specification envisioned that user-agents (browsers) would ask users for their user-id and password and then pass the encoded information to the web server via the HTTP Authorization header.
Basic Auth approach quickly died in popularity in favour of form based login where
Cross-posted from the Oracle Fusion Middleware Blog.
As many of you know, much of today's standards around REST center around IETF based specifications. As such, I thought I would share some RESTful services related news coming from last week's IETF meetings. Many working groups are now in the final stages of moving key specifications into standard status…
This draft was essentially a clean-up of the specification text into IETF format as well as a series of clarifications and fixes that will greatly improve the maturity and interoperability of the SCIM drafts.
On November 13 and 14, the Government of British Columbia, Canada, launched the first in a series of public consultations on identity and digital services. For several years now, BC has been working on a new identity services project that would enable citizens to securely access government services online. For BC, there is clear motivation:
In my last blog post, I discussed the issue of OAuth2 and authentication: Simple Authentication for OAuth 2? What is the Right Approach? As promised, I submitted a draft to the IETF for discussion in Berlin at the beginning of the month. While the working group didn't get a lot of time in the meeting to talk about the authentication issue (it wasn't formally on the charter), the submission did
Over a year ago, several people, including myself, raised concerns about using OAuth (RFC6749) for authentication. By this I mean, that application developers are using OAuth enabled service providers as a way to authenticate their users (using Google, Facebook, LinkedIn, Twitter, or another major provider). They do this because they want to eliminate friction by forcing customers to create
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
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
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.
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.
On my last blog post on Oracle IDM, Marc asks some very good questions that deserve a longer response:
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
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 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.
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
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
The Java JCP has approved a new JSR relating to the use of Identity information within Java. The JSR351 charter is:
To define application programming interfaces and identity interaction models that facilitate and control the use of identity by applications and in access control decisions.
Ron Monzillo gave a talk (presentation available here) at JavaOne on JSR 351, I'll paraphrase his
IIW XII is coming up October 18-20, so I thought I'd share with you a couple of discussions I'd like to open at IIW. The first one is how best to add user identity or authentication information to OAuth2.
The OAuth Identity Information Problem
As many of you know, OAuth2 enables a process whereby a client application, as authorized by a user, is issued a "valet key" (a token) for accessing
I have become recently worried about the rising popularity of informal standards these days. Informality is something that has been rapidly emerging in the rush towards cloud computing. The rush to develop new protocols is often quite important and being done is coming out of critical and urgent need. Many of these groups have achieved early success. Yet they remain afraid that getting the legal
I attended several sessions at IIW last week discussing the new Simple Cloud Identity Management (SCIM) proposal. Already, there have been several positive and negative blog posts on SCIM. I won't try to rehash them, but here are a list of a few:
Martin Kuppinger, Kuppinger-Cole, April 23, SCIM – will SPML shortcomings be reinvented?
Nishant Kaushik, Oracle, April 25, SCIMming the Surface of User
Today I received a question about OAuth and whether it replaces existing federation deployments. Would OAuth, WS-Trust, and SAML work together? The answer is no. In fact, OAuth is built to use any authentication system, local or federated.
Note: Coincidentally, Paul Madsen, also posted an interesting graphic that gives a swim lane view of OAuth's flow with an IDP.
My previous post asked the question "Does OAuth do authentication"? In this post, I explore OAuth2 and its support of authorization.When most people ask the question about whether OAuth2 supports authorization, you might be thinking in terms of today's authorization/access management/policy systems. But, as mentioned in my previous post, authorization here is within the terms of how HTTP defines
I'm not kidding. OAuth itself doesn't seemed to be defined. It's not an acronym just a name. In fact the specification draft simply says:The OAuth 2.0 Authorization Protocol"OAuth" itself isn't spelled out in most places. Wikipedia says its "Open Authorization". But who knows. I can't tell you how many times this question comes up. But if you ask me, it doesn't matter and that is a good thing.
I received a lot of interesting comments on my previous post, "Does OAuth Have Legs". That post was about trying to understand what was meant by legs in OAuth. It included a useful diagram which I have since updated based on feedback. The revised diagram is available below (click to enlarge).A couple of notes:The flows depicted are from the perspective of what a client app has to do to access a
There has been growing interest in a group of protocols, namely HTTP, REST, OAuth, and JSON, and how they can support web services. REST and JSON, have been around for a while, but one of the puzzling problems was how to handle authentication in REST especially for non-browser based clients using HTTP. So far the only options have been BASIC authentication or SSL/TLS mutual authentication. So
I posted a new Internet Draft, the "Chain" grant draft today for the consideration of the OAuth2 working group. The specification defines a new grant type that enables an OAuth protected service to in turn act as an OAuth client to another OAuth protected service. The grant type allows the first server to exchange the current oauth access token for a new token valid on the target service. This
Some folks have been asking, "what's all this stuff about legs in OAuth?" and "I don't understand the difference between 1, 2, and 3 legged OAuth?"I have put together a flow-chart to try and show, from a client app perspective, what constitutes a 1, 2, or 3 legged authorization (click on image to enlarge).Basically the rule of thumb is, each time you make a request response within the OAuth
It's privacy day, and it seems like a good time to re-introduce folks on the long-running Identity Governance Framework project. For a few years now, Oracle has been working hard on laying some privacy groundwork for developers. This project initially started with the development of a standard specification called the Identity Governance Framework. The objective of IGF was simple: define some
It seems many are still looking at OAuth as simply a delegation protocol. I think it is much more. Let's take a moment and highlight some features that go beyond simple delegation, and get at some of the real value behind OAuth.Authentication & The Password Anti-PatternOne way to look at OAuth is that it is a "Proxy Authentication" system. It allows applications acting on a user's behalf (as a
For 5 or more years now, there has been a push by many in the identity management industry to rally around the idea of user-centric identity. Why not give users complete control over information being shared between web sites? From a web service provider it should make sense. Why retain data if it could be provided easily by the user? It made a lot of sense. Thus user-centric identity was born. There was a lot of interest, but user-centricity has remained esoteric and hasn't really taken off...
Continuing the summary of the OAuth Enterprise BOF, I want to call attention to a discussion on session management and OAuth. While we didn't start off talking about it, we soon came to realize a key potential benefit–session management.
As I blogged earlier, it seems like it is time explore the idea of enterprise use of OAuth. Many folks chimed in via email and blog comments that they were interested in a group discussion. So, at IIW 11, folks from Gartner, Google, HP, Paypal, PingIdentity, Salesforce.com, VMWare, Oracle, and others got together for a series of sessions on OAuth at IIW.
As I mentioned yesterday, I've been doing a lot of thinking about OAuth and what it brings to "web" applications. Is delegation really a big deal? I think so. While social networking has developed this protocol and the enterprise community has considered its relevance, something else has been changing and will likely contribute to demand for OAuth. I'm talking about the re-emergence of the intelligent client application and of HTTP itself.
I've been spending some time lately on OAuth and exploring its applicability for enterprise software and the cloud. To date, OAuth's use cases have been focused primarily on social networking. Yet customers are asking, will OAuth be useful? The answer, I believe, is YES!
But first, some background for those new to OAuth...
This past spring, several organizations began a discussion on the SAML TC about the possibility of adding subject and attribute management functions to SAML. The proposal was the subject of a some debate. Why was this an important requirement? Why not use SPML or other protocols?
"Not just write once, run anywhere, but delpoy and deliver anywhere too."
That statement is a quote from Nandini Ramani, Director of Java Development at Oracle (formerly Sun), recently talking about the need for JavaFX in this video. Instead of dealing with the many types of display devices, mobile phones, etc, JavaFX provides a platform for abstracting away the complexities of the myriad of displays and desktops.
Over the past few months, a good deal of progress has been made around IGF and the open source implementation around it. In particular, last fall, Liberty Alliance ratified the IGF 1.0 specification as final. In mid January we published ArisID 1.1, the first open source implementation of IGF 1.0.
I listened to a fascinating show on CBC Radio last Friday that discussed the case of Suaad Hagi Mohamud's detention in Kenya. In this case a woman from Toronto, Canada, who when asked by Canadian embassy officials in Kenya to answer some seemingly basic questions to confirm her identity, failed. So much so, that on May 28, Canada informed Kenya that she was believed to be an imposter and voided her passport, recommending to Kenyan authorities that she be prosecuted. Later on August 10, Suaad's identity was confirmed by DNA after much pressure.