Wednesday, 28 February 2007

PingLogin - Consumer Authentication Management

We recently created this graphic to show how PingLogin was designed from the ground up for extensibility when it came to enabling centralized consumer authentication and session management. The system has four major points of extensibility.

- plugable strong authentication
- plugable 'bindings' for allowing users to authenticate via multiple channels (e.g. HTTP, Flash, Ajax, IVR, Mobile Device)
- plugable session management
- plugable policy

All of this can be configured in such a way that different consumer facing applications (realms) can utilize different combinations of the above.

This provides companies with a logical place to enable CardSpace support and abstract out where strong authentication is integrated. Of course, PingLogin has already been pre-integrated with PingFederate so that your consumer facing applications can do federated single sign-on via both SAML and WS-Federation.

PingLogin

Posted by adurand at 12:57 PM in IdM | Responses (0) | Permalink

Wednesday, 14 February 2007

Find cheese the smart way.

Posted by adurand at 8:51 AM in IdM | Responses (0) | Permalink

Tuesday, 13 February 2007

Ping Identity Product Roadmap

With 2007 upon us, and our engineering teams aligned to meet our 2007 objectives, we thought we'd share some of the highlights of our 2007 roadmap. We anticipate making a few changes in structure to our product line-up, to better focus us on the B2B use cases for partner-facing federation, and the B2C use-cases for consumer authentication.

Expect to see us dig even deeper into enterprise-grade federation as a stand-alone layer of security infrastructure, and accelerate our efforts around consumer authentication with the introduction and foundation of provided for by PingLogin.

Posted by adurand at 12:50 PM in IdM | Responses (0) | Permalink

Why we developed PingLogin

Consumer Authentication - Background

Over the last few years, consumer facing web applications that require some form of security to protect access to their resources have faced a significant increase in issues related to online fraud. Combined with the anticipated need to support new mechanisms and channels for consumer authentication (e.g. CardSpace, OpenID and Higgins, mobile devices, flash, Ajax and voice) many companies are now beginning to rethink their approach to consumer authentication, and their homegrown systems, they realize, are simply not architected to take advantage of many of these anticipated advancements.

That was then…

Most consumer-facing web applications were developed in the mid 1990’s, and implemented only a simplistic userid and password based mechanism to authenticate their consumers. This mechanism has been repeatedly implemented (independently) in some proprietary manner within thousands of web applications. When just requiring a password was enough to authenticate the user (prior to pfishing); implementing an LDAP Bind or a JDBC call to a data store to validate the password, was deemed ‘good enough’, and as a result, most companies rolled their own. To the extent web session management was also required, many companies implemented their won proprietary session token which they then stored in a cookie.

Why not the WAM products?

About the same time we saw the advent of the 1st generation of web access management (WAM) products (e.g. Netegrity, Access360, Securant, ClearTrust, Oblix etc.). While their focus was primarily on the notion of centralized policy management (authorization) for web applications, they also implemented mechanisms to provide user authentication and more importantly single sign-on; but only as a byproduct of offering policy based access management.

Given the cost and complexity of the 1st generation of COTS Web Access Management products, the vast majority of companies with customer facing use-cases chose NOT to deploy these products in their consumer facing scenarios, but instead use them ONLY for internal / employee facing use cases only. This is the dirty little secret we discovered when first approached to build a next generation framework for consumer authentication. The logic was simple, the existing WAM products were deemed too ‘heavy’, too complex and too expensive to deploy for customer/consumer facing applications.

So what about now in 2007?

What was interesting to us here at Ping Identity was that if you roll the clock forward now to 2007, with regards the WAM products, nothings changed. In fact, things have gotten even worse, in that many of the WAM vendors have been acquired, and are now part of an even LARGER, even MORE proprietary or EXPENSIVE stack. That said however, things have changed in the architecture and environments surrounding these products and the need for a new, lightweight, laser focused approach towards consumer authentication. With the advent of SAML, authentication has now become ‘portable’. ISV”s are building SAML into their products and we’re seeing a natural bifurcation of AuthN and AuthZ services. It’s this clean separation of authentication and session management services from policy, authorization and entitlement management that PingLogin was designed to address.

Feeling the Pain

For the first time in several years, companies that rolled their own simplistic password based consumer authentication are feeling the pain and stretch of their systems to the breaking point. And that’s where PingLogin comes in. For those companies now feeling the pain of consumer authentication (need for strong auth, need to support new mechanisms such as CardSpace, OpenID or Higgins, need to support multiple consumer ‘channels’ such as HTTP, AJAX, Flash, Mobile, Voice etc.), the existing products, for all the reasons they weren’t originally chosen, still didn’t suffice. They are still too focused on policy, still to light on authentication flexibility and still deemed too expensive to deploy in consumer facing use-cases.

Most consumer facing applications will have to address strengthening their existing consumer authentication mechanisms over the next two years and consider implementing new methods of consumer authentication. It is highly likely that this will be an iterative process that will continue ad infinitum. The attackers will always be looking to break through the next generation of consumer authentication techniques. It is an arms race that will not decrease, considering online transaction volumes and are likely to continuously increase.

What Ping Identity is doing about it

Starting around a year ago, Ping Identity and two large design partners began working together to create a 2nd generation web authentication product that fundamentally re-addressed the need for extensibility and flexibility when it came to consumer authentication & single sign on. The major design goals for this new product was performance, extensibility and flexibility to address the continuously shifting landscape of online consumer authentication. A landscape that that will be impacted by regulators, consumer whims, the media, and existing and unknown attacks.

Now for the first time, organizations that have implemented their own proprietary system have the opportunity to implement a commercial solution that eliminates maintenance and development going forward while allowing flexibility to meet specific business and risk requirements.

But What if I've Deployed a WAM Product?

Organizations that have implemented an access management product also have the opportunity to migrate to a more focused authentication platform that provides far more extensibility and flexibility to address identity theft and fraud detection. And of course, it works with PingFederate out of the box.

Who Should Take a Closer Look at PingLogin

PingLogin isn't for everyone, but for those organizations that have massive consumer authentication requirements and want a commercially supported framework which is going to provide out-of-box functionality designed for the future of consumer authentication, you should take a closer look. PingLogin 2 is now available for download.

PingLogin Technical Overview | PingLogin Datasheet | Download PingLogin

Posted by adurand at 11:23 AM in IdM | Responses (0) | Permalink

Internet-Scale Identity

What follows is an excerpt from our recently published paper on Internet-Scale Identity Systems.

An Internet-scale identity system is an architecture that defines standardized mechanisms enabling the identity attributes of its users to be shared between applications and Web sites. This enables a streamlined and optimized online experience for users, greater protection from identity theft and opportunities for customization and personalization that do not require the user to manually configure account information. There are a number of different technologies and standards initiatives designed to deliver an Internet-scale identity system including SAML, Windows CardSpace, OpenID and ID-WSF. This white paper provides an overview of the key initiatives and explores the similarities, differences, and synergies between them.

Identity Type

Identity systems typically focus on the exchange of certain types of identity attributes – either unique user identifiers or more general attributes (such as email address, telephone number, user profile information, etc.).

While the communication of an identifier on its own can enable Single Sign-On, richer use cases generally require additional information.

SAML

CardSpace

OpenID

ID-WSF

Identifiers

Allows for a variety of identifier types, from pseudonyms to one-time anonymous.

Allows for IDPs, either self-issued or a third party, to issue a Private Personal Identifier (PPID) by which RP/SPs can recognize the user for authentication.

Default assumption is that users are identified by a personal URI.

Generally assumes that users are identified through pair wise pseudonyms established through a SAML-based identity federation step.

Attributes

Defines a general XML-based syntax for communicating identity attributes, and a protocol by which attribute can be exchanged.

In addition to the PPID claim, RP/SPs can indicate their desire for more general attributes.

CardSpace focuses on personal profile attributes (e.g. name, address, email, etc).

OpenID 2.0 may introduce support for attribute exchange, focusing on attributes typically requested at account registration time.

Enables SOAP-based identity services for sharing general identity attributes beyond user profile information (e.g. geolocation, presence, calendar, etc)

Identifiers

The nature of the identifiers used by RP/SPs to identify users is a key differentiator of identity systems. Most significantly, the nature of the identifier impacts the privacy characteristics of the systems with respect to guarding against inappropriate correlation of user actions at different RP/SPs.

Identifiers used by Identity Systems fall into three general categories:

Global Identifier– all RP/SPs use the same identifier to refer to a given user. While attractively simple, the global model makes collusion trivial between RP/SPs.

Pair-wise Pseudonyms – pairs of providers establish and subsequently use unique identifiers for users. This model inhibits collusion between RP/SPs as they share no common identifier for a user; however, correlation based on other identity characteristics (e.g. phone number) is possible.

One-time Identifier – each time a user accesses an RP/SP they have a different identifier; consequently preventing that RP/SP from correlating their actions across subsequent visits. In such a model, because identifying the user accessing an account at the RP/SP is necessarily impossible, the RP/SP generally customizes service based on other identity attributes of the user (e.g. role in an enterprise scenario, frequent flyer status for a B2C scenario, etc).

SAML supports all of the above identifier types and defines a number of mechanisms tailored to support pseudonyms.

OpenID 1.1 primarily relies on global URIs and inherits the attendant privacy risks. Advocates claim the risk is mitigated by a user’s ability to present different OpenIDs to different RP/SPs as necessary. While true, the implication is that the user bears the burden of remembering and managing multiple URI personas.

ID-WSF and CardSpace primarily rely on pseudonymous identifiers.

Authentication

Single Sign-On enables a user to authenticate to an IDP and then have their digital identity asserted by the IDP to RP/SPs – thereby enabling user access to resources at that RP/SP. For some identity systems, the act of authentication by which the user presents some credentials (e.g. password, OTP, X.509 certificate, IP address, etc.) to the IDP is deemed out of scope – the focus is instead on the protocols and syntax by which this act can be communicated to RP/SPs to enable SSO. Both SAML and OpenID take this approach, neither defines mechanisms by which a user authenticates to the IDP, but rather mechanisms to allow the RP/SP to request that the IDP authenticate the user, and mechanisms to allow the IDP to respond that the user has been authenticated. SAML’s Authentication Context allows the IDP to describe how the authentication occurred (e.g. Biometric or SIM card) but not how to perform it, OpenID is currently exploring comparable functionality.

Alternatively, both CardSpace and ID-WSF define mechanisms by which a user (using a client with capabilities beyond a default browser) can authenticate to an IDP in order to enable subsequent SSO and other identity transactions. Perhaps CardSpace’s most notable functionality is a model where there is no IDP per se. The user authenticates to RP/SPs simply by presenting a previously established identifier and demonstrating possession of a secret cryptographic key to enable protection from the many issues surrounding passwords (i.e. phishing)

Identity Flow

Identity systems can be characterized by the channel through which identity information flows from the IDP to the RP/SP. Fundamentally, there are two high level choices:

· Front Channel – Identity information flows through the user-agent from IDP to RP/SP and thereby makes possible direct user mediation

· Back Channel – Identity information flows direct from IDP to RP/SP

In principle, the front-channel promises improved privacy through the stronger control point enabled by realtime user consent for attribute exchange. Against this must be balanced the reality of insecure clients and the inability of this model to support use cases where the user is offline and not present to actively mediate the identity flow.

Message size limitations of the front-channel method can be addressed through either HTML Form mechanisms or through smart clients capable of more advanced messaging.

SAML

CardSpace

OpenID

ID-WSF

Front-Channel

Supported by various browser mediated bindings

The Enhanced Client Profile also supports ‘smarter’ clients than default browsers.

CardSpace mediates all identity flow – the RP/SP presents its identity request to CardSpace, which forwards the request to the IDP. The returned identity flows the same route in reverse.

The OpenID authentication protocol relies on redirects and HTML Form POSTs through the browser.

ID-WSF allows clients to play an active role in identity exchange, either as requestors, providers, or proxies.

Back-Channel

Supported by the SOAP Binding, providers can communicate directly.

No back-channel. All communications are proxied through CardSpace.

Open ID 2.0 may introduce support for direct communication.

Direct SOAP-based communications between RP/SP and IDP .

Another aspect of identity flow is the point from which identity interactions are initiated. Most typical is a pattern that begins when the RP/SP, in trying to determine access rights or personalization, sends a request to the IDP for the desired identity. A very different set of use cases requires the flow of identity to be initiated from the IDP, and not as a result of a request from the RP/SP. This flow pattern is necessary for portal use cases in which the user, after authenticating to the IDP, can be presented with a list of available RP/SPs with which they have the option of an identity transaction (e.g. a user has seamless access to a partner Web site from a travel portal). The assumption that a particular list of available RP/SPs is presented has implications for the trust model as it requires the IDP to assert identity assertions for the user to only RP/SPs on the list.

	SAML	CardSpace	OpenID	ID-WSF
RP/SP Initiated	Yes	Yes	Yes	Yes
IDP Initiated	Yes (Referred to as “Unsolicited”)	No	No	No

Trust Model

A useful definition of “trust” for the purpose of this white paper is: A reasonable expectation of confidence in an actor’s behavior.

In the context of identity interactions between IDPs and RP/SPs, for one to trust the other means that the first has a reasonable level of confidence that the second will behave in a certain manner in a given context. This may include agreement upon security infrastructure, privacy policies, etc.

Depending on the application, “reasonable” can mean very different things. For low-value and no-risk applications like blog commenting, an RP/SP might establish reasonable confidence in an IDP based solely on the fact that the IDP is able to correctly follow the OpenID SSO protocol. Consequently, such an RP/SP may choose to be indiscriminate in choosing its IDP partners – if there is little or no risk in choosing a bad (malicious, hacked, etc) IDP, the RP/SP is motivated to accept any IDP. Likewise, an IDP assumes no risk by asserting identity to an arbitrary RP/SP because the value or sensitivity of the application creates no great risk to be distributed.

For more sensitive applications (e.g. SSO from a bank IDP to a stock analysis RP/SP), the RP/SP must have a more stringent criteria for determining with which IDPs to engage in identity interactions. If the risk of accepting an assertion from an RP/SP is non-trivial, the RP/SP will manage this risk by being more careful in selecting identity partners. Likewise, an IDP may choose to assert identity to only a certain set of RP/SPs in order to protect itself against risk. Importantly, if IDPs and RP/SPs are anything but completely indiscriminate in their choice of partners, security mechanisms are required to determine whether any particular provider meets selected criteria.

Any of the identity systems discussed in this white paper could support a range of trust models; however, each has been designed or optimized for a particular subset of use cases. OpenID defines a relatively low level of security requirements and is appropriate to low-sensitivity applications. Combined with this is OpenID’s association mechanism for authenticating protocol messages. An RP/SP and IDP, even with no prior relationship, can use Diffie-Helman cryptographic techniques to establish a shared secret key for authenticating subsequent protocol messages. Such a dynamic mechanism is appropriate for OpenID’s default assumption of indiscriminate providers.

SAML and CardSpace define a more robust security model necessary for high-sensitivity use cases. Consequently, SAML and CardSpace are more likely to rely on less dynamic cryptographic mechanisms such as X.509 certificates.

Recently the OpenID community has explored layering security in order to support higher sensitivity use cases, and the SAML community is defining profiles that diminish the security settings from those defined in the core SAML 2.0 specifications.

Discovery

Discovery mechanisms are functions by which – for a given combination of desired user identity, RP/SP identity, and policy requirements – appropriate IDPs can be identified as candidate providers. Discovery is necessary in any architecture in which there are multiple IDPs, or for which the location of IDPs is potentially dynamic. In situations where there is only ever a single identity provider (e.g. an enterprise) there is no need for a discovery operation because any RP/SPs will implicitly know where to obtain the user’s identity attributes.

Discovery is similar to a Web search for an identity. The inputs to the engine are the user in question and the type of identity being sought by the RP/SP. The output is a list of IDPs that meet the criteria.

Discovery can be preceded by a registration step. A step by which IDPs register themselves as providing a particular identity service for a given user. Such a registry could be located on the client or on a network endpoint.

	SAML	CardSpace	OpenID	ID-WSF
Registration	No	Manifested through the installation of managed cards into the CardSpace client.	No	Explicit. Identity services register the fact that they hold identity attributes of a certain type for a given user at that user’s discovery service.
Discovery	Defines an optional cookie mechanism by which RP/SPs can discover IDPs. Allows alternatives.	Implicit. RP/SPs request identity attributes of CardSpace rather than querying for the location of attributes.	Implicit. The RP/SP effectively discovers the IDP by prompting the user for a URI	Explicit. The RP/SP queries a Discovery Service for all services of a given type for a given User.

Posted by adurand at 11:08 AM in IdM | Responses (0) | Permalink

SSO via SAML becoming Agentless

Ping Identity's Patrick Harding and I have been discussing the natural evolution towards SAML for conveying user identity and session cross domain. With it's rise in popularity, it's inevitable that packaged enterprise applications will begin to embed native SAML SP capabilities in future releases of their products. This will likely take 3 years or so, but in the end, the N-state will likely see the the demise of the 'one big proprietary cookie domain' concepts of today's WAM products. Patrick developed these graphics which do a good job at displaying the evolution.

The Trends

Enterprises are asking for Web SSO support from their ISV’s
ISV’s reluctant to implement proprietary WAM cookie schemes
ISV’s looking at standards-based SAML as answer
‘SAML is to User SSO’ as ‘LDAP was to User Auth’

Today

•Mix of WAM agent based SSO and Microsoft Kerberos SSO
•
AD becoming single directory and employee identity store
•
SAML for SSO between disparate security domains or to ESP’s
•
ISV applications support LDAP for single password user authentication

2010

•Agent-less SSO – Kerberos, ADFS and SAML
•
AD is employee identity store
•
SAML for SSO between disparate security domains and to ESP’s
•
ISV applications support SAML for agentless SSO

Posted by adurand at 7:45 AM in IdM | Responses (0) | Permalink

Friday, 9 February 2007

CardSpace / OpenID Demo

Ashish presenting our CardSpace / OpenID integration at the RSA Security Conference.

CardSpace - OpenID Demo

Posted by adurand at 2:18 PM in IdM | Responses (0) | Permalink

Wednesday, 7 February 2007

Open Source CardSpace Apache Module - now available

In addition to the CardSpace/OpenID demo we're doing at the RSA show and the paper we just released this morning comparing and contrasting the various schema's for internet-scale identity, we just this morning released a new open source CardSpace module for Apache. Download it here.

The Apache Authentication Module for CardSpace allows applications using an Apache Web server to use Information Cards as an additional authentication mechanism. It allows LAMP-based Web applications written in Perl or PHP to act as CardSpace relying parties (RP) by means of simple configuration. The module is responsible for decrypting the token submitted by the CardSpace identity selector, retrieving the claims and making the claims available for the application’s use.

“This is an amazing new piece in the identity puzzle,” said Kim Cameron, Chief Architect for Identity and Access, Microsoft Corporation. “Now the benefits from Information Cards and Windows CardSpace can be extended to the full group of Apache users to enable increased security against phishing attacks.”

Posted by adurand at 11:42 AM in IdM | Responses (0) | Permalink

Internet-Scale Identity Systems - free whitepaper

We just published a new whitepaper which discusses approaches around achieving internet-scale identity. It also compares and contrasts the various schemas such as SAML, CardSpace, OpenID and ID-WSF.

An Internet-scale identity system is an architecture that defines standardized mechanisms enabling the identity attributes of its users to be shared between applications and Web sites.

This enables:
- A streamlined and optimized online experience for users
- Greater protection from identity theft
- Opportunities for customization and personalization that do not require the user to manually configure account information

Posted by adurand at 11:31 AM in IdM | Responses (0) | Permalink

Tuesday, 6 February 2007

PingLogin 2 Now Available

We announced today the release of PingLogin 2.

PingLogin has become our focal point for efforts which focus on customer/consumer facing (B2C) identity infrastructure. PingFederate will remain our platform for B2B (partner facing) infrastructure.

Working with two very large financial institutions, we realized that today's IdM systems were not architected (or priced) to deal with the myriad of new and emerging issues facing enterprises that are increasingly focused on how to authenticate and interact with end-users, both in terms of security, and in terms of incorporating new authentication and federation schemas such as CardSpace, OpenID or Higgins.

PingLogin will effectively become a commercial grade option for enterprises looking to deploy customer facing identity and authentication infrastructure over time.