Chuck Mortimore is Director of Product management for Identity & Security at Salesforce.com. His presentation at last year's Cloud Identity Summit was one of my favorite talks an in depth look at oauth and identity in the Cloud, I believe Eve Maler termed it "mind melting conceptual density." Chuck is presenting at this year's Cloud Identity Summit July 18-21 in Colorado. I will also be there doing a talk and a Cloud Security class, its a high point on the conference lineup.
For this Security > 140 conversation, Chuck and I discuss in some detail the architecture choices and constraints for people moving to the Cloud and what Salesforce.com, who I consider a leader in this space, has learned.
GP: One of the first times I worked on deploying SAML was at a Service Provider who had a large customer ask/tell them they had to support SSO via SAML. The SP was not a technology visionary, but they were good at listening to their customers. I have noticed that Salesforce continually has led the way for many Cloud and SaaS providers in identity options. How much is driven by your own tech arch vision and how much is driven by customers?
CM: It's about 50/50. Customers tend to articulate pain, and high level direction. For instance, our customers that have invested in federation consistently ask us to make single sign-on work with mobile and desktop clients. The actual technology strategy to achieve that is then driven by us. Inputs are a combination of our own deployments, understanding of our customer's IT landscape, and evolving best practice on the consumer web. We're also willing to release capabilities and iterate on real feedback.
GP: It seems like SAML and oauth are two standards leading the way currently. Do you see this standards-based trend continuing?
CM: Yes – we see this continuing. We’ve made great progress with Federation standards, and would like to see this trend continue into user provisioning, audit, etc.
GP: What's the likelihood of proprietary identity like Facebook, Apple, and others being used for certain use cases?
CM: We’re pretty customer driven, so these Identity providers are important for consumer driven use-cases. While we don’t have much demand for using these to login directly to our core products, our customers do want to source and maintain relationships with customers from these consumer IDPs. As such, we increasingly integrate with these sources for CRM purposes.
GP: I remember in the 90s people used to call PERL the duct tape of the Internet. Now computing seems to be bifurcating into two modes humongous (Cloud) and tiny (Mobile); and identity is playing a key role, maybe the key role in linking these two models at runtime. You recent Android oauth release is a good example of this. I was surprised that Google did not deliver any web identity model and just stopped at the OS level for security, its very good for the industry that your team filled this gap and published yoru work as open source for others to learn from. What design questions should mobile developers think about when integrating Mobile apps into Cloud providers?
CM: We’ve been focused on a few key challenges with Mobile development
Time to value – we’ve been investing heavily in oauth and optimizing it for mobile experiences. The mobile development experience is complicated enough on it’s own, and the last think developers want to worry about is first writing a bunch of authentication code before they can focus on their core application. With oauth we’re trying to take care of all of that on the developer’s behalf – open up a web browser and wait for a callback.
How does mobile impact your traditional security posture – it’s pretty difficult to really know what applications you’re communicating with to any degree of certainty in a mobile environment. That has ripple effects across traditional perimeter security postures with things like IP restrictions – you want to relax them to some decree for your mobile devices, but are you sure they really are your mobile devices.
We’ve been working on activation and registration protocols to return some degree of control to our customer’s administrations and security staff while still dealing with the influx of consumer mobile devices into IT.
Credentials – a lot of our want to use their own credentials for usability, policy, and lifecycle management reasons, which generally leads to federation or delegation protocols being used. At the same time these same customers are uncomfortable with that credential on mobile devices. This is particularly challenging in the mobile and desktop space, as the well deployed federation protocols tend to use HTTP and web browsers as a substrate for moving messages around. We’ve been investing a lot to weave together oauth and SAML, such that a single investment in federation can be used across a wide variety of device types.
GP: So in weaving these together are you looking to the SAML Bearer Assertion Grant Type Profile to help solve some of this?
CM: We actually took a somewhat simpler route. We have the customer get setup to support SP initiated SAML. We then just treat the Oauth protocol flow like any other deeplink into our site. If the user is un-authenticated, they go through SP Initiated SAML. The Oauth protocol passes through RelayState and once we complete the SAML exchange, we pass them along to complete the Oauth flow. Pretty straightforward. Goal being federate once, and use the same pattern anywhere. We actually can support using the same SAML assertions against our API endpoints as well.
GP: What's been the response from customers and developers on ease of use and implementation? Are the identity concepts easy to grok and something that they understand quickly or is there a lot involved to go from standards, protocols and abstractions to a developer-friendly view?
CM: We’re still feeling this out. The largest usability issue we have is that it requires connecting to a custom url for the customer, and we’re still working on the best model for users or their admins to easily express to the client the url they want to connect to. So – conceptually it’s well received, but we’re still gaining experience on how best to scale the administration/deployment.
GP: What is your current guidance on protecting tokens once they are minted? It seems like the community would benefit from thinking about where the protocol security ends and where host/app security begins.
CM: In general, I try and simplify the language for people new to oauth. Treat refresh_tokens like passwords, and access_tokens like sessions. Use native mechanisms like iOS keychain where ever possible.
Comments