You are on page 1of 4

RealMe vs CardSpace, OpenID & X.

509 Overview The Identity and Access Management world is buzzing with new ideas including a promising technology called OpenID. The hope of OpenID is that a user can have one place they log into on the internet for their entire web browsing needs thus simplifying the current sea of username/passwords that users and websites keep track of. This white paper explores the practical side of OpenID and related technologies from a Software as a Service vendor’s point of view. CardSpace from Microsoft and SAML relationships in general are discussed with advantages and challenges of each technology offered. Finally, the RealMe authentication system from GlobalCrypto is presented. OpenID Open ID is a shared identity service, which allows Internet users to log on to many different web sites using a single digital identity, single sign-on, eliminating the need for a different user name and password for each site. OpenID is a decentralized, free and open standard that lets users control the amount of personal information they provide. An OpenID is in the form of a URL. This URL can be the domain name of your own website, or the URL of an OpenID identity provider. When you log in with an OpenID, you have to log in to the identity provider for validation. Using OpenID-enabled sites, web users do not need to remember traditional items of identity such as username and password. Instead, they only need to be registered with any OpenID "identity provider" (IdP). Since OpenID is decentralized, any website can use OpenID as a way for users to sign in; OpenID does not require a centralized authority to confirm a user's digital identity. Windows CardSpace CardSpace (codenamed InfoCard), is Microsoft's client software for the Identity Metasystem. CardSpace is an instance of a class of identity client software called an Identity Selector. CardSpace stores references to users' digital identities for them, presenting them to users as visual Information Cards. CardSpace provides a consistent UI that enables people to easily use these identities in applications and web sites where they are accepted. Observations on CardSpace & OpenID At first glance OpenID solves a very prominent problem on the internet: Users have too many passwords to remember. The promise of OpenID is to allow a single credential to be used as your authentication for many (all?) of your internet interactions. Card Space seeks to extend simple authentication by attaching attributes to your identity such as physical location and age and makes the OpenID solution a little more flexible yet fuzzy at the same time. Note that when you use CardSpace you are still required to authenticate to the Identity Provider! A Practical Engineer’s impression of the OpenID system is that there are a lot of moving parts. A Service Provider has to redirect initial requests for service to a second party which performs authentication of the end user. This second party

may be an Identity Provider or in the case of CardSpace, another layer of indirection to a third party which must be chosen by the user at runtime based on a selection of possible third party ID providers of information. These types of user-centric identity systems do not offer server-side revocability of credentials and in the case of Card Space are not uniformly cross platform, do not feature exportability/mobility of credentials, use the same cryptographic keys for all services, cannot provide bi-directional trust even while requiring HTTPS, and largely force implementation on .NET platforms. The real drawback to OpenID and CardSpace is a practical one which a Businessman will immediately recognize as an issue of contractual trust. As long as any party on the internet can issue OpenID credentials businesses which need to fundamentally know their customers those businesses will not be able to accept strictly open credentials. Many large internet service providers are already limiting the set of Identity Providers that they will accept as legitimate ID—even in the absence of physical attribute data such as physical location, age or gender. This makes business sense for providers of valuable web services since most businesses have few trusted partners that they are willing to delegate customer tracking to. Customer information is too valuable and the risk of legal action in the event of breech of account access is often likely. Imagine if a city allowed college students to create their own IDs to be able to present at any time for any identification purpose. Bars subject to strict laws forbidding them to serve alcohol to anyone younger than the legal drinking age would quickly reject the new IDs since self issued credentials are worthless for the purpose of proving age. Bars would quickly seek to implement another method for proving identity. In this contrived scenario, the open IDs would be good for applications where the actual identity of a presenting individual wasn’t ultimately important. Think of business mixers where everyone wears “Hello, my name is…” tags where everyone writes in their name and company. You can lie about your name or company, but what’s the point? The online equivalent of these “Hello tag” events are simple social networks, blogs and other semi-anonymous forums. OpenID will be a boon to these types of applications where there isn’t much commerce and the actual identity of individuals isn’t all that important. For business applications on the internet that require an intimate interaction with each user, open ID makes less sense. However there is a middle ground where two companies can have a trusted relationship using concepts from Open ID. Many SaaS vendors already segregate accounts by corporation which makes a lot of sense. An example of this type of segregation is Each company that uses SalesForce has a number of users that have access to that particular company’s data. As employees come and go an administrative rep from the company adds and deletes credentials for each employee to access SalesForce. When several other SaaS vendors are engaged by the above mentioned company the same administrator needs to add credentialed access to each employee for the new service. By spinning up an OpenID style ID provider service for his company and establishing a trusted relationship between each SaaS vendor and his new Id Provider, the corporate administrator can add one credential per employee and effectively have a Web Single Sign On in place through the use of techniques in OpenID. X.509 Certificates The internet relies on X.509 certificates to enable HTTPS sessions between a user and a website. HTTPS sessions are important because they encrypt a browsing

session thereby thwarting packet sniffers. Certificates contain physical information about the presenter of the certificate such as company and address as well as the presenter’s public key. The information bundle is then presumably checked for accuracy and digitally signed by a Certificate Authority such as VeriSign or Thawte. Ideally, a user would also obtain an individual certificate and present it to the website during the HTTPS negotiation which would prove each side’s identity to the other side. This type of negotiation is known as bidirectional certificate exchange and is widely acknowledged to be one of the strongest forms of authentication available on the internet. The question remains, however, of why this type of authentication is not prevalent today? Certificates are theoretically strong, but they have several practical drawbacks. First of all, certificates are very expensive with individual certificates running in the hundreds of dollars annually. Secondly, certificates are very complicated. If you have ever applied for a certificate you are undoubtedly familiar with the terms “Certificate Signing Request”, “pem file”, “PKCS” and other cryptic terms that usually mean that the next few hours of your day are ruined. Applying for a certificate is no fun for seasoned pros and is impossible for the average human. Additionally, once you obtain your certificate and its corresponding private key file there is the matter of where to put it so that your web server or browser can absorb and utilize the information. Installing a certificate is not for the faint of heart and universally involves reading dry instruction pages and manipulating dusty corners of your software configuration that rarely see the light of day. Moreover, with bi-directional certificate exchange there is the matter of how you might revoke a certificate once it is issued. Currently there is a questionable mechanism called Certificate Revocation Lists where a browser or other piece of software is required to traverse a chain of certificates that vouch for each child certificate until the root certificate is reached. In each traversal there is a potential that a particular certificate has been revoked and should not be used. Modern web browsers frequently ignore this feature and even if the browsers did honor the CRLs it takes some time for the CRLs to get distributed across the internet. Bottom Line: certificates have great math, lousy operability and cost a fortune. State of the industry When the state of the industry is taken in totality there are several promising pieces to the authentication puzzle that show the way to a better authentication methodology. The math behind bi-directional certificate exchange is very solid. The user experience of card space is instructive—people understand images as symbols of identity. OpenID and its SAML protocol is a good framework for exchanging authentication information. This brings us to the RealMe authentication system. RealMe Overview The RealMe authentication system from GlobalCrypto leverages the proven math that exists in bi-directional certificate exchange and removes the operational problems that prevent certificates from becoming the preferred method of authentication on the internet. Moreover, RealMe can leverage the technology behind OpenID when it is deployed in a Web Single Sign On configuration to provide Identity claims from a corporation to a trusted web service. RealMe works by inserting cryptographic information into a digital image, splitting that image between a user and an authenticating party and later exchanging these image halves to accomplish a strong, bi-directional authentication.

A RealMe credential –image is a shared token which is digitally signed by the user and the authentication engine. The digital signatures are then steganographically inserted into the image and the image is split in half. The left side goes to the user and the right side goes to the authentication engine. To make the end user’s image whole, a prosthetic right side of the image is tacked on so that the user is given an image that is visually identical to the original image. An RSA key pair is also generated for the user which is encoded into the prosthetic right side of the user’s credential image for later use. Note that all of the above mentioned items inserted into the credential image are password encrypted using AES. The password is never transmitted over the internet and is only used to unlock a credential image at login time. When a user presents her image and password for authentication to a website via a web widget or browser toolbar the image is decrypted and sent to the authenticating web site via an SSL protected xmlHttpRequest. The website provides the right hand side of the credential image and each party to the authentication can verify its digital signature in the reassembled security token. Mathematically, the user is protected and as a final verification, the user visually sees the two halves of her image coming together on the UI. Note that RealMe can be employed at a corporation as a web single sign on for numerous SaaS applications because it is implemented as a Web Service. RealMe is available with a SAML front end that allows SaaS vendors to delegate authentication to a corporate ID provider service. This allows an employee to use one strong credential to login to all of the corporate SaaS providers. Further, the company retains control of the credentialing process in one location. Bottom Line: RealMe is cryptographically strong, very flexible and is user friendly.