Panel tackles how to make mobile devices as secure as they are indispensable

As smartphones have become de rigueur in the global digital economy, users want them to do more work, and businesses want them to be more productive for their employees -- as well as powerful added channels to consumers.

But neither businesses nor mobile-service providers have a cross-domain architecture that supports all the new requirements for a secure digital economy, one that allows safe commerce, data sharing and user privacy.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Ping Identity.

So how do we blaze a better path to a secure mobile future? How do we make today’s ubiquitous mobile devices as low risk as they are indispensable?

BriefingsDirect recently posed these and other questions to a panel of experts on mobile security: Paul Madsen, Principal Technical Architect in the Office of the CTO at Ping Identity; Michael Barrett, President of the FIDO (Fast Identity Online) Alliance, and Mark Diodati, a Technical Director in the Office of the CTO at Ping Identity. The sponsored panel discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: We're approaching this Cloud Identity Summit 2014 (CIS) in Monterey, Calif. on July 19 and we still find that the digital economy is not really reaching its full potential. We're still dealing with ongoing challenges for trust, security, and governance across mobile devices and network.

Even though people have been using mobile devices for decades—and in some markets around the world they're the primary tool for accessing the Internet—why are we still having problems? Why is this so difficult to solve?

Diodati: There are so many puzzle pieces to make the digital economy fully efficient. A couple of challenges come to mind. One is the distribution of identity. In prior years, the enterprise did a decent job -- not an amazing job, but a decent job -- of identifying users, authenticating them, and figuring out what they have access to.

Once you move out into a broader digital economy, you start talking about off-premises architectures and the expansion of user constituencies. There is a close relationship with your partners, employees, and your contractors. But relationships can be more distant, like with your customers.

Emerging threats

Additionally, there are issues with emerging security threats. In many cases, there are fraudsters with malware being very successful at taking people’s identities and stealing money from them.

Diodati

Mobility can do a couple of things for us. In the old days, if you want more identity assurance to access important applications, you pay more in cost and usability problems. Specialized hardware was used to raise assurance. Now, the smartphone is really just a portable biometric device that users carry without us asking them to do so. We can raise assurance levels without the draconian increase in cost and usability problems.

We’re not out of the woods yet. One of the challenges is nailing down the basic administrative processes to bind user identities to mobile devices. That challenge is part cultural and part technology. [See more on a new vision for identity.]

Gardner: So it seems that we have a larger set of variables, end users, are not captive on network, who we authenticate. As you mentioned, the mobile device, the smartphone, can be biometric and can be an even better authenticator than we've had in the past. We might actually be in a better position in a couple of years. Is there a transition that’s now afoot that we might actually come out better on the other end?

Madsen: The opportunities are clear. As Mark indicated, the phones, not just because of its technical features, but because of the relatively tight binding that users feel for them, make a really strong authentication factor.

Madsen

It's the old trope of something you have, something you know, and something you are. Phones are something you already have, from the user’s point of view. It’s not an additional hard token or hard USB token that we're asking employees to carry with them. It's something they want to carry, particularly if it's a BYOD phone.

So phones, because they're connected mobile computers, make a really strong second-factor authentication, and we're seeing that more and more. As I said, it’s one that users are happy using because of the relationship they already have with their phones, for all the other reasons. [See more on identity standards and APIs.]

Gardner: It certainly seems to make sense that you would authenticate into your work environment through your phone. You might authenticate in the airport to check in with your phone and you might use it for other sorts of commerce. It seems that we have the idea, but we need to get there somehow.

What’s architecturally missing for us to make this transition of the phone as the primary way in which people are identified session by session, place by place? Michael, any thoughts about that?

User experience

Barrett: There are a couple of things. One, in today’s world, we don’t yet have open standards that help to drive cross-platform authentication, and we don’t have the right architecture for that. In today’s world still, if you are using a phone with a virtual keyboard, you're forced to type this dreadful, unreadable tiny password on the keyboard, and by the way, you can’t actually read what you just typed. That’s a pretty miserable user experience, which we alluded to earlier.

Barrett

But also, it’s a very ugly. It’s a mainframe-centric architecture. The notion that the authentication credentials are shared secrets that you know and that are stored on some central server is a very, very 1960s approach to the world. My own belief is that, in fact, we have to move towards a much more device-centric authentication model, where the remote server actually doesn’t know your authentication credentials. Again, that comes back to both architecture and standards.

My own view is that if we put those in place, the world will change. Many of us remember the happy days of the late '80s and early '90s when offices were getting wired up, and we had client-server applications everywhere. Then, HTML and HTTP came along, and the world changed. We're looking at the same kind of change, driven by the right set of appropriately designed open standards.

Gardner: So standards, behavior, and technology make for an interesting adoption path, sometimes a chicken and the egg relationship. Tell me about FIDO and perhaps any thoughts about how we make this transition and adoption happen sooner rather than later?

Barrett: I gave a little hint. FIDO is an open-standards organization really aiming to develop a set of technical standards to enable device-centric authentication that is easier for end users to use. As an ex-CTO, I can tell you the experience when you try to give them stronger authenticators that are harder for them to use. They won’t voluntarily use them.

FIDO is an open-standards organization really aiming to develop a set of technical standards to enable device-centric authentication that is easier for end users to use.

We have to do better than we're doing today in terms of ease of use of authentication. We also have to come up with authentication that is stronger for the relying parties, because that’s the other face of this particular coin. In today’s world, passwords and pins work very badly for end users. They actually work brilliantly for the criminals. 

So I'm kind of old school on this. I tend to think that security controls should be there to make life better for relying parties and users and not for criminals. Unfortunately, in today’s world, they're kind of inverted.

So FIDO is simply an open-standards organization that is building and defining those classes of standards and, through our member companies, is promulgating deployment of those standards.

Madsen: I think FIDO is important. Beyond the fact that it’s a standard is the pattern that it’s normalizing. The pattern is one where the user logically authenticates to their phone, whether it be with a fingerprint or a pin, but the authentication is local. Then, leveraging the phone’s capabilities -- storage, crypto, connectivity. etc. -- the phone authenticates to the server. It’s that pattern of a local authentication followed by a server authentication that I think we are going to see over and over.

Gardner: Thank you, Paul. It seems to me that most people are onboard with this. I know that, as a user, I'm happy to have the device authenticate. I think developers would love to have this authentication move to a context on a network or with other variables brought to bear. They can create whole new richer services when they have a context for participation. It seems to me the enterprises are onboard too. So there's a lot of potential momentum around this. What does it take now to move the needle forward? What should we expect to hear at CIS?

Moving forward

Diodati: There are two dimensions to moving the needle forward: avoiding the failures of prior mobile authentication systems, and ensuring that modern authentication systems support critical applications. Both are crucial to the success of any authentication system, including FIDO.

At CIS, we have an in-depth, three-hour FIDO workshop and many mobile authentication sessions. 

There are a couple of things that I like about FIDO. First, it can use the biometric capabilities of the device. Many smart phones have an accelerometer, a camera, and a microphone. We can get a really good initial authentication. Also, FIDO leverages public-key technology, which overcomes some of the concerns we have around other kinds of technologies, particularly one-time passwords. 

Madsen: To that last point Mark, I think FIDO and SAML, or more recent federation protocols, complement each other wonderfully. FIDO is a great authentication technology, and federation historically has not resolved that. Federation didn't claim to answer that issue, but if you put the two together, you get a very strong initial authentication. Then, you're able to broadcast that out to the applications that you want to access. And that’s a strong combination.

Barrett: One of the things that we haven't really mentioned here -- and Paul just hinted at it -- is the relationship between single sign-on and authentication. When you talk to many organizations, they look at that as two different sides of the same coin. So the better application or ubiquity you can get, and the more applications you can sign the user on with less interaction, is a good thing.

Gardner: Before we go a little bit deeper into what’s coming up, let’s take another pause and look back. There have been some attempts to solve these problems. Many, I suppose, have been from a perspective of a particular vendor or a type of device or platform or, in an enterprise sense, using what they already know or have.

Proprietary technology is really great for many things, but there are certain domains that simply need a strong standards-based backplane.

We've had containerization and virtualization on the mobile tier. It is, in a sense, going back to the past where you go right to the server and very little is done on the device other than the connection. App wrapping would fall under that as well, I suppose. What have been the pros and cons and why isn’t containerization enough to solve this problem? Let’s start with Michael.

Barrett: If you look back historically, what we've tended to see are lot of attempts that are truly proprietary in nature. Again, my own philosophy on this is that proprietary technology is really great for many things, but there are certain domains that simply need a strong standards-based backplane.

There really hasn't been an attempt at this for some years. Pretty much, we have to go back to X.509 to see the last major standards-based push at solving authentication. But X.509 came with a whole bunch of baggage, as well as architectural assumptions around a very disconnected world view that is kind of antithetical to where we are today, where we have a very largely connected world view.

I tend to think of it through that particular set of lenses, which is that the standards attempts in this area are old, and many of the approaches that have been tried over the last decade have been proprietary.

For example, on my old team at PayPal, I had a small group of folks who surveyed security vendors. I remember asking them to tell me how many authentication vendors there were and to plot that for me by year?

Growing number of vendors

They sighed heavily, because their database wasn’t organized that way, but then came back a couple of weeks later. Essentially they said that in 2007, it was 30-odd vendors, and it has been going up by about a dozen a year, plus or minus some, ever since, and we're now comfortably at more than 100.

Any market that has 100 vendors, none of whose products interoperate with each other, is a failing market, because none of those vendors, bar only a couple, can claim very large market share. This is just a market where we haven’t seen the right kind of approaches deployed, and as a result, we're struck where we are today without doing something different.

Gardner: Paul, any thoughts on containerization, pros and cons?

Madsen: I think of phones as almost two completely orthogonal aspects. First is how you can leverage the phone to authenticate the user. Whether it’s FIDO or something proprietary, there's value in that.

Secondly is the phone as an application platform, a means to access potentially sensitive applications. What mobile applications introduce that’s somewhat novel is the idea of pulling down that sensitive business data to the device, where it can be more easily lost or stolen, given the mobility and the size of those devices.

IT, arguably and justifiably, wants to protect the business data on it, but the employee, particularly in a BYOD case, wants to keep their use of the phone isolated and private.

The challenge for the enterprise is, if you want to enable your employees with devices, or enable them to bring their own in, how do you protect that data. It seems more and more important, or recognized as the challenge, that you can’t.

The challenge is not only protecting the data, but keeping the usage of the phone separate. IT, arguably and justifiably, wants to protect the business data on it, but the employee, particularly in a BYOD case, wants to keep their use of the phone isolated and private.

So containerization or dual-persona systems attempt to slice and dice the phone up into two or more pieces. What is missing from those models, and it’s changing, is a recognition that, by definition, that’s an identity problem. You have two identities—the business user and the personal user—who want to use the same device, and you want to compartmentalize those two identities, for both security and privacy reasons.

Identity standards and technologies could play a real role in keeping those pieces separate.The employee might use Box for the business usage, but might also use it for personal usage. That’s an identity problem, and identity will keep those two applications and their usages separate.

Diodati: To build on that a little bit, if you take a look at the history of containerization, there were some technical problems and some usability problems. There was a lack of usability that drove an acceptance problem within a lot of enterprises. That’s changing over time.

To talk about what Michael was talking about in terms of the failure of other standardized approaches to authentication, you could look back at OATH, which is maybe the last big industry push, 2004-2005, to try to come up with a standard approach, and it failed on interoperability. OATH was a one-time password, multi-vendor  capability. But in the end, you really couldn’t mix and match devices. Interoperability is going to be a big, big criteria for acceptance of FIDO. [See more on identity standards and APIs.]

Mobile device management

Gardner: Another thing out there in the market now, and it has gotten quite a bit of attention from enterprises as they are trying to work through this, is mobile device management (MDM).  Do you have any thoughts, Mark, on why that has not necessarily worked out or won’t work out? What are the pros and cons of MDM?

Diodati: Most organizations of a certain size are going to need an enterprise mobility management solution. There is a whole lot that happens behind the scenes in terms of binding the user's identity, perhaps putting a certificate on the phone.

Michael talked about X.509. That appears to be the lowest common denominator for authentication from a mobile device today, but that can change over time. We need ways to be able to authenticate users, perhaps issue them certificates on the phone, so that we can do things like IPSec.

Also, we may be required to give some users access to offline secured data. That’s a combination of apps and enterprise mobility management (EMM) technology. In a lot of cases, there's an EMM gateway that can really help with giving offline secure access to things that might be stored on network file shares or in SharePoint, for example.

If there's been a stumbling block with EMM, it's just been that the heterogeneity of the devices, making it a challenge to implement a common set of policies.

The fundamental issue with MDM is, as the name suggests, that you're trying to manage the device, as opposed to applications or data on the device.

But also the technology of EMM had to mature. We went from BlackBerry Enterprise Server, which did a pretty good job in a homogeneous world, but maybe didn't address everybody’s needs. The AirWatchs and the Mobile Irons of the world, they've had to deal with heterogeneity and increased functionality.

Madsen: The fundamental issue with MDM is, as the name suggests, that you're trying to manage the device, as opposed to applications or data on the device. That worked okay when the enterprise was providing employees with their BlackBerry, but it's hard to reconcile in the BYOD world, where users are bringing in their own iPhones or Androids. In their mind, they have a completely justified right to use that phone for personal applications and usage.

So some of the mechanisms of MDM remain relevant, being able to wipe data off the phone, for example, but the device is no longer the appropriate granularity. It's some portion of the device that the enterprise is authoritative over.

Gardner: It seems to me, though, that we keep coming back to several key concepts: authentication and identity, and then, of course, a standardization approach that ameliorates those interoperability and heterogeneity issues. [See more on a new vision for identity.]

So let’s look at identity and authentication. Some people make them interchangeable. How should we best understand them as being distinct? What’s the relationship between them and why are they so essential for us to move to a new architecture for solving these issues? Let’s start with you, Michael.

Identity is center

Barrett: I was thinking about this earlier. I remember having some arguments with Phil Becker back in the early 2000s when I was running the Liberty Alliance, which was the standards organization that came up with SAML 2.0. Phil coined that phrase, "Identity is center," and he used to argue that essentially everything fell under identity.

What I thought back then, and still largely do, is that identity is a broad and complex domain. In a sense, as we've let it grow today, they're not the same thing. Authentication is definitely a sub-domain of security, along with a whole number of others. We talked about containerization earlier, which is a kind of security-isolation technique in many regards. But I am not sure that identity and authentication are exactly in the same dimension.

In fact, the way I would describe it is that if we talk about something like the levels-of-assurance model, we're all fairly familiar with in the identity sense. Today, if you look at that, that’s got authentication and identity verification concepts bound together.

Today, we've collapsed them together, and I am not sure we have actually done anybody any favors by doing that.

In fact, I suspect that in the coming year or two, we're probably going to have to decouple those and say that it’s not really a linear one-dimensonal thing, with level one, level two, level three, and level four. Rather it's a kind of two-dimensional metric, where we have identity verification concepts on one side and then authentication comes from the other. Today, we've collapsed them together, and I am not sure we have actually done anybody any favors by doing that.

Definitely, they're closely related. You can look at some of the difficulties that we've had with identity over the last decade and say that it’s because we actually ignored the authentication aspect. But I'm not sure they're the same thing intrinsically. 

Gardner: Interesting. I've heard people say that any high-level security mobile device has to be about identity. How else could it possibly work? Authentication has to be part of that, but identity seems to be getting more traction in terms of a way to solve these issues across all other variables and to be able to adjust accordingly over time and even automate by a policy.

Mark, how do you see identity and authentication? How important is identity as a new vision for solving these problems?

Diodati: You would have to put security at the top, and identity would be a subset of things that happen within security. Identity includes authorization -- determining if the user is authorized to access the data. It also includes provisioning. How do we manipulate user identities within critical systems -- there is never one big identity in the sky. Identity includes authentication and a couple of other things.

To answer the second part of your question, Dana, in the role of identity and trying to solve these problems, we in the identity community have missed some opportunities in the past to talk about identity as the great enabler.

With mobile devices, we want to have the ability to enforce basic security controls , but it’s really about identity. Identity can enable so many great things to happen, not only just for enterprises, but within the digital economy at large. There's a lot of opportunity if we can orient identity as an enabler.

Authentication and identity

Madsen: I just think authentication is something we have to do to get to identity. If there were no bad people in the world and if people didn’t lie, we wouldn’t need authentication.

We would all have a single identifier, we would present ourselves, and nobody else would lay claim to that identifier. There would be no need for strong authentication. But we don’t live there. Identity is fundamental, and authentication is how we lay claim to a particular identity.

Diodati: You can build the world's best authorization policies. But they are completely worthless, unless you've done the authentication right, because you have zero confidence that the users are who they say there are.

Gardner: So, I assume that multifactor authentication also is in the subset. It’s just a way  of doing it better or more broadly, and more variables and devices that can be brought to bear. Is that correct?

Madsen: Indeed.

We have to apply a set of adaptive techniques to get better identity assurance about the user.

Diodati: The definition of multifactor has evolved over time too. In the past, we talked about “strong authentication”. What we mean was “two-factor authentication,” and that is really changing, particularly when you look at some of the emerging technologies like FIDO.

If you have to look at the broader trends around adaptive authentication, the relationship to the user or the consumer is more distant. We have to apply a set of adaptive techniques to get better identity assurance about the user.

Gardner: I'm just going to make a broad assumption here that the authentication part of this does get solved, that multifactor authentication, adaptive, using devices that people are familiar with, that they are comfortable doing, even continuing to use many of the passwords, single sign-on, all that gets somehow rationalized.

Then, we're elevated to this notion of identity. How do we then manage that identity across these domains? Is there a central repository? Is there a federation? How would a standard come to bear on that major problem of the federation issue, control, and management and updating and so forth? Let’s go back to Michael on that.

Barrett: I tend to start from a couple of different perspectives on this. One is that we do have to fix the authentication standards problem, and that's essentially what FIDO is trying to do.

So, if you accept that FIDO solves authentication, what you are left with is an evolution of a set of standards that, over the last dozen years or so, starting with SAML 2.0, but then going on up through the more recent things like OpenID Connect and OAuth 2.0, and so on, gives you a robust backplane for building whatever business arrangement is appropriate, given the problem you are trying to solve.

Liability

I chose the word "business" quite consciously in there, because it’s fair to say that there are certain classes of models that have stalled out commercially for a whole bunch of reasons, particularly around the dreaded L-word, i.e, liability.

We tried to build things that were too complicated. We could just describe this grand long-term vision of what the universe looked like. Andrew Nash is very fond of saying that we can describe this rich ecosystem as identity-enabled services and so on, but you can’t get there from here, which is the punch line of a rather old joke.

Gardner: Mark, we understand that identity is taking on a whole new level of importance. Are there some examples that we can look to that illustrate how an identity-centric approach to security, governance, manageability for mobile tier activities, even ways it can help developers bring new application programming interfaces (APIs) into play and context for commerce and location, are things we haven’t even scratched the surface of yet really?

Identity is pretty broad when you take a look at the different disciplines that might be at play.

Help me understand, through an example rather than telling, how identity fits into this and what we might expect identity to do if all these things can be managed, standards, and so forth.

Diodati: Identity is pretty broad when you take a look at the different disciplines that might be at play. Let’s see if we can pick out a few.

We have spoken about authentication a lot. Emerging standards like FIDO are important, so that we can support applications that require higher assurance levels with less cost and usability problems.

A difficult trend to ignore is the API-first development modality. We're talking about things like OAuth and OpenID Connect. Both of those are very important, critical standards when we start talking about the use of API- and even non-API HTTP based stuff.

OpenID Connect, in particular, gives us some abilities for users to find where they want to authenticate and give them access to the data they need. The challenge is that the mobile app is interacting on behalf of a user. How do you actually apply things like adaptive techniques to an API session to raise identity assurance levels? Given that OpenID Connect was just ratified earlier this year, we're still in early stages of how that’s going to play out.

Gardner: Michael, any thoughts on examples, use cases, a vision for how this should work in the not too distant future?

Barrett: I'm a great believer in open standards, as I think I have shown throughout the course of this discussion. I think that OpenID Connect, in particular, and the fact that we now have that standard ratified, [is useful]. I do believe that the standards, to a very large extent, allow the creation of deployments that will address those use-cases that have been really quite difficult [without these standards in place].

Ahead of demand

The problem that you want to avoid, of course, is that you don’t want a standard to show up too far ahead of the demand. Otherwise, what you wind up with is just some interesting specification that never gets implemented, and nobody ever bothers deploying any of the implementations of it.

So, I believe in just-in-time standards development. As an industry, identity has matured a lot over the last dozen years. When SAML 2.0 came along in Shibboleth, it was a very federation-centric world, addressing a very small class of use cases. Now, we have a more robust sets of standards. What’s going to be really interesting is to see, how those new standards get used to address use cases that the previous standards really couldn’t?

I'm a bit of a believer in sort of Darwinian evolution on this stuff and that, in fact, it’s hard to predict the future now. Niels Bohr famously said, "Prediction is hard, especially when it involves the future.” There is a great deal of truth to that.

Prediction is hard, especially when it involves the future.

Gardner: Hopefully we will get some clear insights at the Cloud Identity Summit this month, July 19, and there will be more information to be had there.

I also wonder whether we're almost past the point now when we talk about mobile security, cloud security, data-center security. Are we going to get past that, or is this going to become more of a fabric of security that the standards help to define and then the implementations make concrete? Before we sign off, Mark, any last thoughts about moving beyond segments of security into a more pervasive concept of security?

Diodati: We're already starting to see that, where people are moving towards software as a service (SaaS) and moving away from on-premises applications. Why? A couple of reasons. The revenue and expense model lines up really well with what they are doing, they pay as they grow. There's not a big bang of initial investment. Also, SaaS is turnkey, which means that much of the security lifting is done by the vendor.

That's also certainly true with infrastructure as a service (IaaS). If you look at things like Amazon Web Services (AWS). It is more complicated than SaaS, it is a way to converge security functions within the cloud.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Ping Identity.

You may also be interested in:

• As the Digital Economy Ramps Up, Expect a New Identity Management Vision to Leapfrog Passwords
• Standards and APIs: How to Build Platforms and Tools to Best Manage Identity and Security
• The Open Group and MIT Experts Detail New Advances in Identity Management to Help Reduce Cyber Risk
• Effective Enterprise Security Begins and Ends with Architectural Best Practices Approach
• BYOD Brings New Challenges for IT: Allowing Greater Access while Protecting Networks
• Identify and Access Management as a Service Gets Boost with SailPoint's IdentityNow Cloud Service
• Identity Governance Becomes Must-Do Items on Personnel Management and Security Checklist

As the digital economy ramps up, expect a new identity management vision to leapfrog passwords

A stubborn speed bump continues to hobble the digital economy. We're referring to the outdated use of passwords and limited identity-management solutions that hamper getting all of our devices, cloud services, enterprise applications, and needed data to work together in anything approaching harmony. 

The past three years have seen a huge uptick in the number and types of mobile devices, online services, and media. Yet, we're seemingly stuck with 20-year-old authentication and identity-management mechanisms -- mostly based on passwords.

The resulting chasm between what we have and what we need for access control and governance spells ongoing security lapses, privacy worries, and a detrimental lack of interoperability among cross-domain cloud services. So, while a new generation of standards and technologies has emerged, a new vision is also required to move beyond the precarious passel of passwords that each of us seems to use all the time.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.

The fast approaching Cloud Identity Summit 2014 this July gives us a chance to recheck some identity-management premises -- and perhaps step beyond the conventional to a more functional mobile future. To help us define these new best ways to manage identities and access control in the cloud and mobile era, please join me in welcoming our guest, Andre Durand, CEO of Ping Identity. The discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: The Cloud Identity Summit is coming up, and at the same time, we're finding that this digital economy is not really reaching its potential. There seems to be this ongoing challenge, as we have more devices, varieties of service and this need for this cross-domain interaction capability. It’s almost as if we're stymied. So why is this problem so intractable? Why are we still dealing with passwords and outdated authentication?

Durand: Believe it or not, you have to go back 30 years to when the problem originated, when the Internet was actually born. Vint Cerf, one of the founders and creators of the Internet, was interviewed by a reporter two or three years back. He was asked if he could go back 30 years, when he was creating the Internet, what would he do differently? And he thought about it for a minute and said, "I would have tackled the identity problem."

Durand

He continued, "We never expected the Internet to become the Internet. We were simply trying to route packets between two trusted computers through a standardized networking protocol. We knew that the second we started networking computers, you needed to know who the user was that was making the request, but we also knew that it was a complicated problem." So, in essence, they punted.

Roll forward 30 years, and the bulk of the security industry and the challenges we now face in identity management at scale, Internet or cloud scale, all result from not having tackled identity 30 years ago. Every application, every device, every network that touches the Internet has to ask you who you are. The easiest way to do that is via user name and password, because there was no concept of who the user was on the network at a more fundamental universal layer.

So all this password proliferation comes as a result of the fact that identity is not infrastructure today in the Internet, and it's a hard problem to retrofit the Internet for a more universal notion of who you are, after 30 years of proliferating these identity silos. 

Internet of things

Gardner: It certainly seems like it’s time, because we're not only dealing with people and devices. We're now going into the Internet of Things, including sensors. We have multiple networks and more and more application programming interfaces (APIs) and software-as-a-service (SaaS) applications and services coming online. It seems like we have to move pretty quickly. [See more on identity standards and APIs.]

Durand: We do. The shift that began to exacerbate, or at least highlight, the underlying problem of identity started with cloud and SaaS adoption, somewhere around 2007-2008 time frame. With that, it moved some of the applications outside of the data center. Then, starting around 2010 or 2011, when we started to really get into the smartphone era, the user followed the smartphone off the corporate network and the corporate-issued computer and onto AT and T’s network.

So you have the application outside of the data center. You have the user off the network. The entire notion of how to protect users and data broke. It used to be that you put your user on your network with a company-issued computer accessing software in the data center. It was all behind the firewall.

Those two shifts changed where the assets were, the applications, data, and the user. The paradigm of security and how to manage the user and what they have access to also had to shift and it just brought to light the larger problem in identity.

What we need is the ability for your identity to follow your browser session, as you're moving between all these security domains.

Gardner: And the stakes here are fairly high. We're looking at a tremendously inefficient healthcare system here in the United States, for example. One of the ways that could be ameliorated and productivity could be increased is for more interactions across boundaries, more standards applied to how very sensitive data can be shared. If we can solve this problem, it seems to me there is really a flood of improvement in productivity to come behind it.

Durand: It's enormous and fundamental. Someone shared with me several years ago a simple concept that captures the essence of how much friction we have in the system today in and around identity and users in their browsers going places. The comment was simply this: In your browser you're no longer limited to one domain. You're moving between different applications, different websites, different companies, and different partners with every single click.

What we need is the ability for your identity to follow your browser session, as you're moving between all these security domains, and not have to re-authenticate yourself every single time you click and are off to a new part of the Internet.

We need that whether that means employees sitting at their desktop on a corporate network, opening their browser and going to Salesforce.com, Office 365, Gmail, or Box, or whether it means a partner going into another partner’s application, say to manage inventory as part of their supply chain.

We have to have an ability for the identity to follow the user, and fundamentally that represents this next-gen notion of identity.

Gardner: I want to go back to that next-gen identity definition in a moment, but I notice you didn't mention authenticate through biometrics to a phone or to a PC. You're talking, I think, at a higher abstraction, aren’t you? At software or even the services level for this identity. Or did I read it wrong?

Stronger authentication

Durand: No, you read it absolutely correctly. I was definitely speaking at 100,000 feet there. Part of the solution that I play out is what's coming in the future will be stronger authentication to fewer places, say stronger authentication to your corporate network or to your corporate identity. Then, it's a seamless ability to access all the corporate resources, no matter if they're business applications that are proprietary in the data center or whether or not the applications are in the cloud or even in the private cloud.

So, stronger user authentication is likely through the mobile phone, since the phones have become such a phenomenal platform for authentication. Then, once you authenticate to that phone, there will be a seamless ability to access everything, irrespective of where it resides.

Gardner: Then, when you elevate to that degree, it allows for more policy-driven and intelligence-driven automated and standardized approaches that more and more participants and processes can then adopt and implement. Is that correct?

Durand: That’s exactly correct. We had a notion of who was accessing what, the policy, governance, and the audit trail inside of the enterprise, and that was through the '80s, '90s, and the early 2000s. There was a lot of identity management infrastructure that was built to do exactly that within the enterprise.

We now live in this much more federated scenario, and there is a new generation of identity management that we have to install.

Gardner: With directories.

Durand: Right, directories and all the identity management, Web access management, identity-management provisioning software, and all the governance software that came after that. I refer to all of those systems as Identity and Access Management 1.0.

It was all designed to manage this, as long as all the applications, user, and data were behind the firewall on the company network. Then, the data and the users moved, and now even the business applications are moving outside the data center to the public and private cloud.

We now live in this much more federated scenario, and there is a new generation of identity management that we have to install to enable the security, auditability, and governance of that new highly distributed or federated scenario.

Gardner: Andre, let’s go back to that "next-generation level" of identity management. What did you mean by that? 

Durand:  There are few tenets that fall into the next-generation category. For me, businesses are no longer a silo. Businesses are today fundamentally federated. They're integrating with their supply chain. They're engaging with social identities, hitting their consumer and customer portals. They're integrating with their clients and allowing their clients to gain easier access to their systems. Their employees are going out to the cloud.

Fundamentally integrated

All of these are scenarios where the IT infrastructure in the business itself is fundamentally integrated with its customers, partners, and clients. So that would be the first tenet. They're no longer a silo.

The second thing is that in order to achieve the scale of security around identity management in this new world, we can no longer install proprietary identity and access management software. Every interface for how security and identity is managed in this federated world needs to be standardized.

So we need open identity standards such as SAML, OAuth, and OpenID Connect, in order to scale these use cases between companies. It’s not dissimilar to an era of email, before we had Internet e-mail and the SMTP standard.

Companies had email, but it was enterprise email. It wouldn’t communicate with other companies' proprietary email. Then, we standardized email through SMTP and instantly we had Internet-scaled email.

I predict that the same thing is occurring, and will occur, with identity. We'll standardize all of these cases to open identity standards and that will allow us to scale the identity use cases into this federated world.

So whatever infrastructure we develop needs to normalize the API and mobile access the same way that it does the web access.

The third tenet is that, for many years, we really focused on the browser and web infrastructure. But now, you have users on mobile devices and applications accessing APIs. You have as many, if not most, transactions occurring through the API mobile channel than you do through the web.

So whatever infrastructure we develop needs to normalize the API and mobile access the same way that it does the web access. You don’t want two infrastructures for those two different channels of communication. Those are some of the big tenets of this new world that define an architecture for next-gen identity that’s very different from everything that came before it.

Gardner: To your last tenet, how do we start to combine without gaps and without security issues the ability to exercise a federated authentication and identity management capability for the web activities, as well as for those specific APIs and specific mobile apps and platforms?

Durand: I’ll give you a Ping product specific example, but it’s for exactly that reason that we kind of chose the path that we did for this new product. We have a product called PingAccess, which is a next-gen access control product that provides both web access management for the web browsers and users using web application. It provides API access management when companies want to expose their APIs to developers for mobile applications and to other web services.

Prior to PingAccess in a single product, allowing you to enable policy for both the API channel and the web channel, those two realms typically were served by independent products. You'd buy one product to protect your APIs and you’d buy another product to do your web-access management.

Same product

Now with this next-gen product, PingAccess, you can do both with the same product. It’s based upon OAuth, an emerging standard for identity security for web services, and it’s based upon OpenID Connect, which is a new standard for single sign-on and authentication and authorization in the web tier. [See more on identity standards and APIs.]

We built the product to cross the chasm, between API and web, and also built it based upon open standards, so we could really scale the use cases.

Gardner: Whenever you bring out the words "new" and "standard," you'll get folks who might say, "Well, I'm going to stick with the tried and true." Is there any sense of the level of security, privacy control management, and governance control with these new approaches, as you describe them, that would rebut that instinct to stick with what you have?

Durand: As far as the instinct to stick with what you have, keep in mind that the alternative is proprietary, and there is nothing about proprietary that necessarily means you have better control or more privacy.

There's a tremendous amount of the work that goes into it by the entire industry to make sure that those standards are secure and privacy enabling.

The standards are really defining secure mechanisms to pursue a use case between two different entities. You want a common interface, a common language to communicate. There's a tremendous amount of the work that goes into it by the entire industry to make sure that those standards are secure and privacy enabling.

I'd argue that it's more secure and privacy enabling than the one-off proprietary systems and/or the homegrown systems that many companies developed in the absence of these open standards.

Gardner: Of course, with standards, it's often a larger community, where people can have feedback and inputs to have those standards evolve. That can be a very powerful force when it comes to making sure that things remain stable and safe. Any thoughts about the community approach to this and where these standards are being managed?

Durand: A number of the standards are being managed now by the Internet Engineering Task Force (IETF), and as you know, they're well-regarded, well-known, and certainly well-recognized for their community involvement and having a cycle of improvement that deals with threats, as they emerge, as the community sees them, as a mechanism to improve the standards over time to close those security issues.

Gardner: Going back to the Cloud Identity Summit 2014, is this a coming-out party of sorts for this vision of yours? How do you view the timing right now? Are we at a tipping point, and how important is it to get the word out properly and effectively?

Durand: This is our fifth annual Cloud Identity Summit. We've been working toward this combination of where identity and the cloud and mobile ultimately intersect. All of the trends that I described earlier today -- cloud adoption, mobile adoption, moving the application and the user and the device off the network -- is driving more and more awareness towards a new approach to identity management that is disruptive and fundamentally different than the traditional way of managing identity.

On the cusp

We're right on the cusp where the adoption across both cloud and mobile is irrefutable. Many companies now are moving all in in their strategies to make adoption by their enterprises across those two dimensions a cloud-first and mobile-first posture.

So it is at a tipping point. It's the last nail in the coffin for enterprises to get them to realize that they're now in a new landscape and need to reassess their strategies for identity, when the business applications, the ones that did not convert to SaaS, move to Amazon Web Services, Equinix, or to Rackspace and the private-cloud providers.

That, all of a sudden, would be the last shift where applications have left the data center and all of the old paradigms for managing identity will now need to be re-evaluated from the ground up. That’s just about to happen.

Gardner: Another part of this, of course, is the user themselves. If we can bring to the table doing away with passwords, that itself might encourage a lot of organic adoption and calls for this sort of a capability. Any sense of what we can do in terms of behavior at the user level and what would incentivize them to knock on the door of their developers or IT organization and ask for this sort of capability and vision that we described.

When you experience an ability to get to the cloud, authenticating to the corporation first, and simply swipe with your mobile phone, it just changes how we think about authentication and how we think about the utility of having a smartphone with us all the time.

Durand: Now you're highlighting my kick-off speech at PingCon, which is Ping’s Customer and Partner Conference the day after the Cloud Identity Summit. We acquired a company and a technology last year in mobile authentication to make your mobile phone the second factor, strong authentication for corporations, effectively replacing the one-time tokens that have been issued by traditional vendors for strong authentication.

It’s an application you load on your smartphone and it enables you an ability to simply swipe across the screen to authenticate when requested. We'll be demonstrating the mobile phone as a second-factor authentication. What I mean there is that you would type in your username and password and then be asked to swipe the phone, just to verify your identity before getting into the company.

We'll also demonstrate how you can use the phone as a single-factor authentication. As an example, let’s say I want to go to some cloud service, Dropbox, Box, or Salesforce. Before that, I'm asked to authenticate to the company. I'd get a notification on my phone that simply says, "Swipe." I do the swipe, it already knows who I am, and it just takes me directly to the cloud. That user experience is phenomenal.

When you experience an ability to get to the cloud, authenticating to the corporation first, and simply swipe with your mobile phone, it just changes how we think about authentication and how we think about the utility of having a smartphone with us all the time.

Gardner: This aligns really well, and the timing is awesome for what both Google with Android and Apple with iOS are doing in terms of being able to move from screen to screen seamlessly. Is that something that’s built in this as well?

If I authenticate through my mobile phone, but then I end up working through a PC, a laptop, or any other number of interfaces, is this is something that carries through, so that I'm authenticated throughout my activity?

Entire vision

Durand: That's the entire vision of identity federation. Authenticate once, strongly to the network, and have an ability to go everywhere you want -- data center, private cloud, public SaaS applications, native mobile applications -- and never have to re-authenticate.

Gardner: Sounds good to me, Andre. I'm all for it.  Before we sign off, do we have an example? It's been an interesting vision and we've talked about the what and how, but is there a way to illustrate to show that when this works well perhaps in an enterprise, perhaps across boundaries, what do you get and how does it work in practice?

Durand: There are three primary use cases in our business for next-generation identity, and we break them up into workforce, partner, and customer identity use cases. I'll give you quick examples of all three.

In the workforce use case, what we see most is a desire for enterprises to enable single sign-on to the corporation, to the corporate network, or the corporate active directory, and then single-click access to all the applications, whether they're in the cloud or in the data center. It presents employees in the workforce with a nice menu of all their application options. They authenticate once to see that menu and then, when they click, they can go anywhere without having to re-authenticate.

That's the entire vision of identity federation. Authenticate once, strongly to the network.

That's primarily the workforce use case. It's an ability for IT to control what applications, where they're going in the cloud, what they can do in the cloud to have an audit trail of that, or have full control over the use of the employee accessing cloud applications. The next-gen solutions that we provide accommodate that use case.

The second use case is what we call a customer portal or a customer experience use case. This is a scenario where customers are hitting a customer portal. Many of the major banks in the US and even around the world use Ping to secure their customer website. When you log into your bank to do online banking, you're logging into the bank, but then, when you click on any number of the links, whether to order checks, to get check fulfillment, that goes out to Harland Clarke or to Wealth Management.

That goes to a separate application. That banking application is actually a collection of many applications, some run by partners, some by run by different divisions of the bank. The seamless customer experience, where the user never sees another login or registration screen, is all secured through Ping infrastructure. That’s the second use case.

The third use case is what we call a traditional supply chain or partner use case. The world's largest retailer is our customer. They have some 100,000 suppliers that access inventory applications to manage inventory at all the warehouses and distribution centers.

Prior to having Ping technology, they would have to maintain the username and password of the employees of all those 100,000 suppliers. With our technology they allow single sign-on to that application, so they no longer have to manage who is an employee of all of those suppliers. They've off-loaded the identity management back to the partner by enabling single sign-on.

About 50 of the Fortune 100 are all Ping customers. They include Best Buy, where you don’t have to login to go to the reward zone. You're actually going through Ping.

If you're a Comcast customer and you log into comcast.net and click on any one of the content links or email, that customer experience is secured though Ping. If you log into Marriott, you're going through Ping. The list goes on and on.

In the future

Gardner: This all comes to a head as we're approaching the July Cloud Identity Summit 2014 in Monterey, Calif., which should provide an excellent forum for keeping the transition from passwords to a federated, network-based intelligent capability on track.

Before we sign-off, any idea of where we would be in a year from now? Is this a stake in the ground for the future or something that we could extend our vision toward in terms of what might come next, if we make some strides and a lot of what we have been talking about today gets into a significant uptake and use.

Durand: We're right on the cusp of the smartphone becoming a platform for strong, multi-factor authentication. That adoption is going to be fairly quick. I expect that, and you're going to see enterprises adopting en masse stronger authentication using the smartphone.

Gardner: I suppose that is an accelerant to the bring-your-own-device (BYOD) trend. Is that how you see it as well?

We're right on the cusp of the smartphone becoming a platform for strong, multi-factor authentication.

Durand: It’s a little bit orthogonal to BYOD. The fact that corporations have to deal with that phenomenon brings its own IT headaches, but also its own opportunities in terms of the reality of where people want to get work done.

But the fact that we can assume that all of the devices out there now are essentially smartphone platforms, very powerful computers with lots of capabilities, is going to allow the enterprises now to leverage that device for really strong multi-factor authentication to know who the user is that’s making that request, irrespective of where they are -- if they're on the network, off the network, on a company-issued computer or on their BYOD.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Ping Identity.

You may also be interested in:

• Standards and APIs: How to Build Platforms and Tools to Best Manage Identity and Security
• The Open Group and MIT Experts Detail New Advances in Identity Management to Help Reduce Cyber Risk
• Effective Enterprise Security Begins and Ends with Architectural Best Practices Approach
• BYOD Brings New Challenges for IT: Allowing Greater Access while Protecting Networks
• Identify and Access Management as a Service Gets Boost with SailPoint's IdentityNow Cloud Service
• Identity Governance Becomes Must-Do Items on Personnel Management and Security Checklist

Standards and APIs: How to best manage identity and security in the mobile era

The advent of the application programming interface (API) economy has forced a huge, pressing need for organizations to both seek openness and improve security for accessing mobile applications, data, and services anytime, anywhere, and from any device.

Awash in inadequate passwords and battling subsequent security breaches, business and end-users alike are calling for improved identity management and federation technologies. They want workable standards to better chart the waters of identity management and federation, while preserving the need for enterprise-caliber risk remediation and security.

Meanwhile, the mobile tier is becoming an integration point for scads of cloud services and APIs, yet unauthorized access to data remains common. Mobile applications are not yet fully secure, and identity control that meets audit requirements is hard to come by. And so developers are scrambling to find the platforms and tools to help them manage identity and security, too.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Ping Identity.

Clearly, the game has clearly changed for creating new and attractive mobile processes, yet the same old requirements remain wanting around security, management, interoperability, and openness.

BriefingsDirect assembled a panel of experts to explore how to fix these pressing needs: Bradford Stephens, the Developer and Platforms Evangelist in the CTO’s Office at Ping Identity; Ross Garrett, Senior Director of Product Marketing at Axway, Kelly Grizzle, Principal Software Engineer at SailPoint Technologies. The sponsored panel discussion is moderated by me, Dana Gardner, Principal Analyst at Interarbor Solutions.

Here are some excerpts:

Gardner: We are approaching the Cloud Identity Summit 2014 (CIS), which is coming up on July 19 in Monterey, Calif. There's a lot of frustration with identity services that meet the needs of developers and enterprise operators as well. So let’s talk a little bit about what’s going on with APIs and identity.

What are the trends in the market that keep this problem pressing? Why is it so difficult to solve?

Interaction changes

Stephens: Well, as soon as we've settled on a standard, the way we interact with computers changes. It wasn’t that long ago that if you had Active Directory and SAML and you hand-wrote security endpoints of model security products, you were pretty much covered.

Stephens

But in the last three or four years, we've gone to a world where mobile is more important than web. Distributed systems are more important than big iron. And we communicate with APIs instead of channels and SDKs, and that requires a whole new way of thinking about the problem.

Garrett: Ultimately, APIs are becoming the communication framework, the fabric, in which all of the products that we touch today talk to each other. That, by extension, provides a new identity challenge. That’s a lot of reason why we've seen some friction and schizophrenia around the types of identity technologies that are available to us.

So we see waves of different technologies come and go, depending on what is the flavor of the month. That has caused some frustration for developers, and will definitely come up during our Cloud Identity Summit in a couple of weeks.

Grizzle: APIs are becoming exponentially more important in the identity world now. As Bradford alluded to, the landscape is changing. There are mobile devices as well as software-as-a-service (SaaS) providers out there who are popping up new services all the time. The common thread between all of them is the need to be able to manage identities. They need to be able to manage the security within their system. It makes total sense to have a common way to do this.

Grizzle

APIs are key for all the different devices and ways that we connect to these service providers. Becoming standards based is extremely important, just to be able to keep up with the adoption of all these new service providers coming on board.

Gardner: As we describe this as the API economy, I suppose it’s just as much a marketplace and therefore, as we have seen in other markets, people strive for predominance. There's jockeying going on. Bradford, is this a matter of an architectural shift? Is this a matter of standards? Or is this a matter of de-facto standards? Or perhaps all of the above?

Stephens: It’s getting complex quickly. I think we're settling on standards, like it or not, mostly positively. I see most people settling on at least OAuth 2.0 as a standard token, and OpenID Connect for implementation and authentication of information, but I think that’s about as far as we get.

There's a lot of struggle with established vendors vying to implement these protocols. They try to bridge the gap between the old world of say SAML and Active Directory and all that, and the new world of SCIM, OAuth, OpenID Connect. The standards are pretty settled, at least for the next two years, but the tools, how we implement them, and how much work it takes developers to implement them, are going to change a lot, and hopefully for the better.

Evolving standards

Garrett: We have identified a number of new standards that are bridging this new world of API-oriented connectivity. Learning from the past of SAML and legacy, single sign-on infrastructure, we definitely need some good technology choices.

Garrett

The standards seem to be leading the way. But by the same token, we should keep a close eye on the market changing with regards to how fast standards are changing. We've all seen things like OAuth progress slower than some of the implementations out there. This means the ratification of the standard was happening after many providers had actually implemented it. It's the same for OpenID Connect.

We are in line there, but the actual standardization process doesn’t always keep up with where the market wants to be.

Gardner: We've seen this play out before that the standards can lag. Getting consensus, developing the documentation and details, and getting committees to sign off can take time, and markets move at their own velocity. Many times in the past, organizations have hedged their bets by adopting multiple standards or tracking multiple ways of doing things, which requires federation and integration.

Kelly, are there big tradeoffs with standards and APIs? How do we mitigate the risk and protect ourselves by both adhering to standards, but also being agile in the market?

Grizzle: That’s kind of tricky. You're right in that standards tend to lag. That’s just part and parcel of the standardization process. It’s like trying to pass a bill through Congress. It can go slow.

You're right in that standards tend to lag. That’s just part and parcel of the standardization process.

Something that we've seen some of these standards do right, from OAuth and from the SCIM perspective, is that both of those have started their early work with a very loose standardization process, going through not one of the big standards bodies, but something that can be a little bit more nimble. That’s how the SCIM 1.0 and 1.1 specs came out, and they came out in a reasonable time frame to get people moving on it.

Now that things have moved to the Internet Engineering Task Force (IETF), development has slowed down a little bit, but people have something to work with and are able to keep up with the changes going on there.

I don’t know that people necessarily need to adopt multiple standards to hedge their bets, but by taking what’s already there and keeping a pulse on the things that are going to change, as well as the standard being forward-thinking enough to allow some extensibility within it, service providers and clients, in the long run, are going to be in a pretty good spot.

Quick primer

Gardner: We've talked a few technical terms so far, and just for the benefit of our audience, I'd like to do a quick primer, perhaps with you Bradford. To start: OAuth, this is with the IETF now. Could you just quickly tell the audience what OAuth is, what it’s doing, and why it’s important when we talk about API, security and mobile?

Stephens: OAuth is the foundation protocol for authorization when it comes to APIs for web applications. OAuth 2 is much more flexible than OAuth 1.

Basically, it allows applications to ask for access to stuff. It seems very vague, but it’s really powerful once you start getting the right tokens for your workflows. And it provides the same foundation for everything else we do for identity and APIs.

The best example I can think of is when you log into Facebook, and Facebook asks whether you really want this app to see your birthday, all your friends’ information, and everything else. Being able to communicate all that over the OAuth 2.0 is a lot easier than how it was with OAuth 1.0 a few years ago.

Gardner: How about OpenID Connect. This is with the OpenID Foundation. How does that relate, and what is it?

If OAuth actually is the medium, OpenID Connect can be described as the content of the message. It’s not the message itself.

Stephens: If OAuth actually is the medium, OpenID Connect can be described as the content of the message. It’s not the message itself. That’s usually done with the Token, Javascript object notation (JSON) Web Token, but OpenID Connect provides the actual identity information.

When you access an API and you authenticate, you choose a scope, and one of the most common scopes is OpenID Profile. This OpenID Profile will just have things like your username, maybe your address, various other pieces of identity information, and it describes who the "you" is, who you are.

Gardner: And SCIM, you mentioned that Kelly, and I know you have been involved with it. So why don’t you take the primer for SCIM, and I believe it’s Simple Cloud Identity Management?

Grizzle: That's the historical name for it, Simple Cloud Identity Management. When we took the standard to the IETF, we realized that the problems that we were solving were a little bit broader than just the cloud and within the cloud. So the acronym now stands for the System for Cross-domain Identity Management.

That’s kind of a mouthful, but the concept is pretty simple. SCIM is really just an API and a schema that allows you to manage identities and identity-related information. And by manage them, I mean to create identities in systems to delete them, update them, change the entitlements and the group memberships, and things like that.

Gardner: From your perspective, Kelly, what is the relationship then between OAuth and SCIM?

Managing identities

Grizzle: OAuth, as Bradford mentioned, is primarily geared toward authorization, and answers the question, "Can Bob access this top-secret document?" SCIM is really not in the authorization and authentication business at all. SCIM is about managing identities.

OAuth assumes that an identity is already present. SCIM is able to create that identity. You can create the user "Bob." You can say that Bob should not have access to that top-secret document. Then, if you catch Bob doing some illicit activity, you can quickly disable his account through a SCIM call. So they fit together very nicely.

Gardner: In the real world, developers like to be able to use APIs, but they might not be familiar with all the details that we've just gone through on some of these standards and security approaches.

How do we make this palatable to developers? How do we make this something that they can implement without necessarily getting into the nitty-gritty? Are there some approaches to making this a bit easier to consume as a developer?

The best thing we can do is have tool-providers give them tools in their native language or in the way developers work with things.

Stephens: As a developer who's relatively new to this field -- I worked in database for three years -- I've had personal experience of how hard it is to wrap your head around all the standards and all these flows and stuff. The best thing we can do is have tool providers give them tools in their native language, or in the way developers work with things.

This needs well-documented, interactive APIs -- things like Swagger -- and lots of real-world code examples. Once you've actually done the process of authentication through OAuth, getting a JSON Web Token, and getting an OpenID Connect profile, it’s really  simple to see how it all works together, if you do it all through a SaaS platform that handles all the nitty-gritty, like user creation and all that.

If you have to roll your own, though, there's not a lot of information out there besides the WhitePages and Wall Post. It’s just a nightmare. I tried to roll my own. You should never roll your own.

So having SaaS platforms to do all this stuff, instead of having documents, means that developers can focus on providing their applications, and just understand that I have this media and project, not about which tokens carry information that accesses OAuth and OpenID Connect.

I don’t really care how it all works together; I just know that I have this token and it has the information I need. And it’s really liberating, once you finally get there.

So I guess the best thing we can do is provide really great tools that solve the identity-management problems.

Tools: a key point

Garrett: Tools, that’s the key point here. Whether we like it or not, developers tend to be kind of lazy sometimes and they certainly don’t have the time or the energy to understand every facet of the OAuth specification. So providing tools that can wrap that up and make it as easy to implement as possible is really the only way that we get to really secure mobile applications or any API interaction. Because without a deep understanding of how this stuff works, you can make pretty fundamental errors.

Having said that, at least we've started to take steps in the right direction with the standards. OAuth is built at least with the idea of mobile access in mind. It’s leveraging REST and JSON types, rather than SOAP and XML types, which are really way too heavyweight for mobile applications.

So the standards, in their own right, have taken us in the right direction, but we absolutely need tools to make it easy for developers.

Grizzle: Tools are of the utmost importance, and some of the identity providers and people with skin in the game, so to speak, are helping to create these tools and to open-source them, so that they can be used by other people.

Identity isn’t the most glamorous thing to talk about, except when it all goes wrong, and some huge leak makes the news headlines.

Another thing that Ross touched on was keeping the simplicity in the spec. These things that we're addressing -- authorization, authentication, and managing identities -- are not extremely simple concepts always. So in the standards that are being created, finding the right balance of complexity versus completeness and flexibility is a tough line to walk.

With SCIM, as you said, the first initial of the acronym used to stand for Simple. It’s still a guiding principle that we use to try to keep these interactions as simple as possible. SCIM uses REST and JSON, just like some of these other standards. Developers are familiar with that. Putting the burden on the right parties for implementation is very important, too. To make it easy on clients, the ones who are going to be implementing these a lot, is pretty important.

Gardner: Do these standards do more than help the API economy settle out and mature? Cloud providers or SaaS providers want to provide APIs and they want the mobile apps to consume them. By the same token, the enterprises want to share data and want data to get out to those mobile tiers. So is there a data-management or brokering benefit that goes along with this? Are we killing multiple birds with one set of standards?

Garrett: The real issue here, when we think about the new types of products and services that the API economy is helping us deliver, is around privacy and ultimately customer confidence. Putting the user in control of who gets to access which parts of my identity profile, or how contextual information about me can perhaps make identity decisions easier, allows us to lock down, or better understand, these privacy concerns that the world has.

Identity isn’t the most glamorous thing to talk about -- except when it all goes wrong -- and some huge leak makes the news headlines, or some other security breach has lost credit-card numbers or people’s usernames and passwords.

Hand in hand

In terms of how identity services are developing the API economy, the two things go hand in hand. Unless people are absolutely certain about how their information is being used, they simply choose not to use these services. That’s where all the work that the API management vendors and the identity management vendors are doing and bringing that together is so important.

Gardner: You mentioned that identity might not be sexy or top of mind, but how else can you manage all these variables on an automated or policy-driven basis? When we move to the mobile tier, we're dealing with multiple networks. We're dealing with multiple services ... cloud, SaaS, and APIs. And then we're linking this back to enterprise applications. How other than identity can this possibly be managed?

Stephens: Identity is often thought of as usernames and passwords, but it’s evolving really quickly to be so much more. This is something I harp on a lot, but it’s really quickly becoming that who we are online is more important than who we are in real life. How I identify myself online is more important than the driver's license I carry in my wallet.

And it’s important that developers understand that because any connected application is going to have to have a deep sense of identity.

As you know, your driver’s license is like a real-life token of information that describes what you're allowed to do in your life. That’s part of your identity. Anybody who has lost their license knows that, without that, there's not a whole lot you can do.

Bringing that analogy back to the Internet, what you're able to access and what access you're able to give other people or other applications to change important things, like your Facebook posts, your tweets, or go through your email and help categorize that is important. All these little tasks that help define how you live, are all part of your identity. And it’s important that developers understand that because any connected application is going to have to have a deep sense of identity.

Gardner: Let me pose the same question, but in a different way. When you do this well, when you can manage identity, when you can take advantage of these new standards that extend into mobile requirements and architectures, with the API economy in mind, what do you get? What does it endow you with? What can you do that perhaps you couldn’t do if you were stuck in some older architectures or thinking?

Grizzle: Identity is key to everything we do. Like Bradford was just saying, the things that you do online are built on the trust that you have with who is doing them. There are very few services out there where you want completely anonymous access. Almost every service that you use is tied to an identity.

So it’s of paramount importance to get a common language between these. If we don’t move to standards here, it's just going to be a major cost problem, because there are a ton of different providers and clients out there.

If every provider tries to roll their own identity infrastructure, without relying on standards, then, as a client, if I need to talk to two different identity providers, I need to write to two different APIs. It’s just an explosive problem, with the amount that everything is connected these days.

So it’s key. I can’t see how the system will stand up and move forward efficiently without these common pieces in place.

Use cases

Gardner: Do we have any examples along these same lines of what do you get when you do this well and appropriately based on what you all think is the right approach and direction? We've been talking at a fairly abstract level, but it really helps solidify people’s thinking and understanding when they can look at a use-case, a named situation or an application.

Stephens: If you want a good example of how OAuth delegation works, building a Facebook app or just working on Facebook app documentation is pretty straightforward. It gives you a good idea of what it means to delegate certain authorization.

Likewise, Google is very good. It’s very integrated with OAuth and OpenID Connect when it comes to building things on Google App Engine.

The thing that these new identity service providers have been offering has, behind the scenes, been making your lives more secure.

So if you want to secure an API that you built using Google Cloud on Google App Engine, which is trivial to do, Google Cloud Endpoints provides a really good example. In fact, there is a button that you can hit in their example button called Use OAuth and that OAuth transports OpenID Connect profile, and that’s a pretty easy way to go about it.

Garrett: I'll just take a simple consumer example, and we've touched on this already. It was the idea in the past, where every individual service or product is offering only their identity solution. So I have to create a new identity profile for every product or service that I'm using. This has been the case for a long time in the consumer web and in the enterprise setting as well.

So we have to be able to solve that problem and offer a way to reuse existing identities. It involves so taking technologies like OpenID Connect, which is totally hidden to the end user really, but simply saying that you can use this existing identity, your LinkedIn or  Facebook credentials, etc., to access some new products, takes a lot of burden away from the consumer. Ultimately, that provides us a better security model end to end.

The thing that these new identity service providers have been offering has, behind the scenes, been making your lives more secure. Even though some people might shy away from using their Facebook identity across multiple applications, in many ways it’s actually better to, because that’s really one centralized place where I can actually see, audit, and adjust the way that I'm presenting my identity to other people.

That’s a really great example of how these new technologies are changing the way we interact with products everyday.

Standardized approach

Grizzle: At SailPoint, the company that I work for, we have a client, a large chip maker, who has seen the identity problem and really been bitten by it within their enterprise. They have somewhere around 3,500 systems that have to be able to talk to each other, exchange identity data, and things like that.

The issue is that every time they acquire a new company or bring a new group into the fold, that company has its own set of systems that speak their own language, and it takes forever to get them integrated into their IT organization there.

So they've said that they're not going to support every app that these people bring into the IT infrastructure. They're going with SCIM and they are saying that all these apps that come in, if they speak SCIM, then they'll take ownership of those and pull them into their environment. It should just plug in nice and easy. They're doing it just because of a resourcing perspective. They can't keep up with the amount of change to their IT infrastructure and keep everything automated.

They can't keep up with the amount of change to their IT infrastructure and keep everything automated.

Gardner: I want to quickly look at the Cloud Identity Summit that’s coming up. It sounds like a lot of these issues are going to be top of mind there. We're going to hear a lot of back and forth and progress made.

Does this strike you, Bradford, as a tipping point of some sort, that this event will really start to solidify thinking and get people motivated? How do you view the impact of this summit on cloud identity?

Stephens: At CIS, we're going to see a lot of talk about real-world implementation of these standards. In fact, I'm running the Enterprise API track and I'll be giving a talk on end-to-end authentication using JAuth, OAuth, and OpenID Connect. This year is the year that we show that it's possible. Next year, we'll be hearing a lot more about people using it in production.

Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Ping Identity.

You may also be interested in:

• The Open Group and MIT Experts Detail New Advances in Identity Management to Help Reduce Cyber Risk
• Effective Enterprise Decurity Begins and Ends with Architectural Best Practices Approach
• BYOD Brings New Challenges for IT: Allowing Greater Access while Protecting Networks
• Identify and Access Management as a Service Gets Boost with SailPoint's IdentityNow Cloud Service
• Identity Governance Becomes Must-Do Items on Personnel Management and Security Checklist