Transcript of a BriefingsDirect podcast on how strides are being made to develop identity standards and smooth the way for developers to use them quickly and easily.

1. Standards and APIs: How to Best Build Platforms and Tools
to Manage Identity and Security
Transcript of a BriefingsDirect podcast on how strides are being made to develop identity
standards and smooth the way for developers to use them quickly and easily.
Listen to the podcast. Find it on iTunes. Sponsor: Ping Identity
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're
listening to BriefingsDirect. Today, we present a sponsored podcast discussion on
the pressing need for improved identity management and federation technologies,
as well as workable standards and best practices for the application programming
interface (API) economy.
We'll examine how business and end-user trends are forcing organizations to both
seek openness and improve security for accessing applications, APIs, data, and
services anytime, anywhere, and from any device.
Developers are scrambling to find the platforms and tools to help them manage identity 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.
So while the game has changed for creating new and attractive mobile processes,
the same old requirements around security, management, interoperability, and
openness remain wanting.
We'll now hear from a panel of experts on how to better chart the waters of identity management
and federation, while preserving the need for enterprise-caliber risk remediation and security.
With that, please join me now in welcoming our guests. We're here with Bradford Stephens, the
Developer and Platforms Evangelist in the CTO’s Office at Ping Identity. Welcome, Bradford.
Bradford Stephens: Hello. Thanks for having me.
Gardner: We're also here with Ross Garrett, Senior Director of Product Marketing at Axway.
Good to have you with us, Ross.
Ross Garrett: Good to be here.
Gardner: And we're also here with Kelly Grizzle, Principal Software Engineer at SailPoint
Technologies. Welcome, Kelly.
Gardner

2. Kelly Grizzle: Thanks, Dana. Happy to talk to you.
Gardner: We are approaching the Cloud Identity Summit 2014, which is coming up on July 19
in Monterey, California. There's a lot of frustration with identity services that meet the need of
developers and enterprise operators as well. So let’s talk a little bit about what’s going on with
APIs and why they don’t always comply with security policies and infrastructure.
First to you, Bradford. From a high level, 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 handwrote security endpoints of model security products, you were pretty
much covered.
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
Gardner: Anything to offer on that, Ross? How do you see the challenge?
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 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.
Gardner: Kelly, how has the role of APIs, as we have now been describing them, changed the
identity world? How do you see this API and identity collision?
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.
Stephens
Grizzle

3. 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
Gardner: Ross, do you agree that we've settled on the handful of standards that we need, or at
least the major ones, and that this is a matter now of implementation? How do you view the
evolution?
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.
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
Garrett

4. 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.
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.

5. Gardner: How about OpenID Connect. This is with the OpenID Foundation. How does that
relate, and what is it?
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 towards 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.

6. How do we make this palatable to developers? How do we make this something that they can
implement without necessarily getting into the actual nitty-gritty? Are there some approaches to
making this a bit easier to consume as a developer? I'll start with Bradford.
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.

7. 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.
Gardner: Do you have anything to offer on that, Kelly, in terms of maybe a service-provider
role? As an identity service provider yourself, is there something that intermediary can bring to
help developers and automate some of these issues?
Grizzle: I think so. Bradford and Ross hit on a lot of it. 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.
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? Let me start with Ross.
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

8. 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, Bradford?
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.
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, to Kelly. 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.

9. Use cases
Gardner: 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, do we have any examples? 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 or even a named situation or an application.
Let’s go down our list of panelists, starting with Bradford. Are there any examples, either use
cases or named organizations that you can publicly go to and say that here is an example of how
it can really work well?
Stephens: For all this we have to see around for other people on this. An example where we
have seen OAuth, OpenID and SCIM all working together elegantly in an easy to use public
access API.
Now, that being said, 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.google cloud endpoints
Likewise, Google is very good. It’s very integrated with OAuth and OpenID Connect when it
comes to building things on Google App Engine.
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.
Gardner: Ross, any thoughts on use cases, examples, or ways that we can illustrate the power of
this when all the pieces come together?
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

10. 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
Gardner: Kelly, any thoughts on illustrating how this works well as a standardized approach
rather than the one off?
Grizzle: Absolutely. At SailPoint, the company that I work for, we have a client, a large
chipmaker, 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.
Gardner: We're about out of time. 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.
Gardner: Well, great. I'm afraid we will have to leave it there. You've been listening to a
sponsored BriefingsDirect podcast discussion on the pressing need for improved identity

11. management and federation technologies, as well as workable standards and best practices for
the API economy.
While we've seen how unauthorized access to data remains a problem, and mobile application
aren't always secure, we're beginning to see a lot of progress made in ways that standards can be
used to extend safety while increasing the ability for developers to get their jobs done.
So a big thanks to our guests. We've been here with Bradford Stephens, Developer and Platforms
Evangelist in the CTO’s Office at Ping Identity. Thanks so much, Bradford.
Stephens: Thank you, everybody else. You made this one really interesting.
Gardner: Also, we have been pleased to have Ross Garrett with us. He's the Senior Director of
Product Marketing at Axway. Thank you, sir.
Garrett: Thank you very much.
Gardner: And lastly, Kelly Grizzle has joined us, the Principal Software Engineer at SailPoint
Technologies. Thanks so much for your input.
Grizzle: Thanks for inviting me, Dana.
Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. A big thanks to our
audience for joining us as well. You can find more information on these subjects at the IETF, at
Ping Identity, Axway, SailPoint Technologies, and of course there will be a lot of information
generated at the Cloud Identity Summit on July 19.
So once again to our audience thanks for listening, and don’t forget to come back next time.
Listen to the podcast. Find it on iTunes. Sponsor: Ping Identity
Transcript of a BriefingsDirect podcast on how strides are being made to develop identity
standards and smooth the way for developers to use them quickly and easily. Copyright
Interarbor Solutions, LLC, 2005-2014. All rights reserved.
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

12. •
Identity Governance Becomes Must-Do Items on Personnel Management and Security
Checklist