Operations // Identity & Access Management
2/19/2014
12:05 PM
Patrick Harding
Patrick Harding
Commentary
Connect Directly
Twitter
Google+
LinkedIn
RSS
E-Mail
50%
50%
Repost This

'Connect': A Modern Approach To Mobile, Cloud Identity

A new protocol from the OpenID Foundation promises enterprises federated single sign-on that can scale.

I don't need to tell anyone about the problems with passwords. The focus should be on looking forward to a development coming next week that provides the best shot yet to improve security in growing mobile and social environments. 

It's called OpenID Connect. It's a protocol, and it should be on enterprise radar screens as an authentication building block for SaaS, mobile apps, and other resources, available via a multitude of devices that are currently suffering from a lack of credible access controls. 

Infrastructure isn't sexy, but when not done right it can contribute to issues that are downright scary, such as millions of passwords and accounts stolen last year from retailers and service providers far and wide.

Connect has been described as “the DHCP for identity” because it promises scalable single sign-on at a time when connections are crisscrossing among companies, service providers, and business partners.  It’s technology that is coming around the corner and promises to bring options to enterprise users looking for federated single sign-on at scale for mobile and cloud environments

OpenID Connect v. OpenID 2.0
The protocol forms part of a modern architecture for identity and access management to support mobile, cloud and API-integration scenarios.

Connect is not the OpenID 2.0 protocol that many in the industry have discounted over the years. In fact, Connect erases the sins and deficiencies of the past.  The protocol is a simple identity layer built on top of the Internet Engineering Task Force standard OAuth 2.0. From a very high level,  OAuth is about granting access, while Connect is about authentication. Simply put, Connect provides the pattern for how to securely pass identity information.

Both OAuth and Connect tuck into Web architectures and align with the Internet trend toward simple, light and functional (including standards such as Representational State Transfer (REST) and JavaScript Object Notation (JSON)) as opposed to heavy and highly architected standards. These developments not only align with app developers, but also administrators, who can avoid punching holes in firewalls by using simple REST calls associated with Connect.

In addition, Connect provides a single security protocol for both B2C and B2B environments, and offers multiple grades of authentication. The protocol is API-friendly and adapts to native and mobile applications. It supports robust signing and encryption. Now that approval is imminent, I expect it to be an important building block in access control strategies going forward.

Enterprise building block
Enterprises are acutely aware that they need to address new security concerns in distributed architectures that feature cloud services, transparent security boundaries, and untethered, device-crazy end-users.

Connect will aid in reducing the number of sign-on credentials end-users must remember to a few secure accounts that are maintained by trusted identity providers --  including the enterprise. And it can be used by any number of clients for authentication to resources. 

The spec confines complexity to a single place and enables a consistent, secure, predictable experience that improves chances of detecting fraudulent use of identity.  It has been in development for the past four years, and has been tested in production environments at Salesforce, Google, Microsoft, Yahoo, and many others.

The OpenID Foundation, which has fostered development of the standard, also has developed a common user interface, called Account Chooser, aimed at standardizing sign-on procedures to reduce end-user confusion.

It's true that no one buys protocols, but Connect is shaping up to be one important building block and an area for enterprises to explore.

Patrick Harding is responsible for the Ping Identity product and technology strategy. He brings more than 20 years of software development, networking infrastructure, and information security to the role, which includes oversight of the Office of the CTO and Ping Labs. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
2/19/2014 | 5:04:47 PM
Security without passwords
Interesting approach, Patrick. I'm curious about how "Connect" squares with the efforts of the FIDO Alliance and its proposed new authentication standards for password-free computing. 
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web