Tag Archives: openid

RSA 2010

If you are going to be at the RSA Conference this year, we look forward to talking with you.

The RSA Security Expo
Monday March 1st – Thursday March 4th

VeriSign Booth #1717
(see map below)

San Francisco, CA
Moscone Center

This year, we’ve worked with VeriSign to integrate TrustBearer’s technology with VeriSign’s Managed PKI (MPKI) product, and we’ll be showing demos of this joint solution at the VeriSign booth.

We’ll also be showing our updated OpenID and SAML identity provider, which now allows users to register their computer with VeriSign MPKI. Similarly, users with PIV and CAC smart cards, and many other security devices, can use their credential for multi-factor authentication to web applications like Google Apps, Salesforce, and Basecamp.

If you would like to schedule a meeting with us during the conference, send us an email: sales@trustbearer.com.

To learn what we are up to during the conference, follow us on Twitter: @trustbearer.


Emerging Technology Presentation from CTST

Earlier this week I gave a presentation on an Emerging Technology panel at Card Tech Secure Tech (CTST) in New Orleans. Much of the content was taken from the Virginia Security Summit presentation given a week prior, but I elaborated on using smart cards for strong authentication. A couple of the slides got into using digital certificates to prove someone’s “real” identity to a relying party using OpenID extensions and digital certificate path discovery & validation.

Where do we go from here? I would like to see some of the identity verification concepts that I touched on in the presentation be tested in a pilot. There are also opportunities here to evolve the OpenID specs and extensions, such as PAPE. TrustBearer would like to continue this discussion and explore some pilot ideas. Contact me if you are interested.

Presentation on OpenID, SAML and Authentication

This past Monday I gave a presentation as part of the Identity Management track at the first Virginia Security Summit in Richmond, VA. The audience here was a mixture of Virginia state & local technology decision makers (CIO / CTO) and implementers. This included local government, education and transportation representatives.

The session description was rather broad.

A comprehensive security plan has to start with user authentication. It is not an easy task when the range of users is constantly growing and shifting, as are potential threats. Using just one tactic is not enough – it takes a combination of technologies and procedures. This session looks at the latest technologies and approaches as well as their strengths and shortcomings.

So, I decided to give a primer on the Security Assertion Markup Language (SAML) and OpenID single sign on standards. At the beginning of the presentation I took a poll of the crowd and found that about one quarter of those in attendance (~50 people) knew something about each of these standards.

In addition to comparing and contrasting SAML and OpenID, I also talked about several strong authentication options available for each of these SSO standards. I basically wanted to convey that there are better options then making users (citizens) create yet another username & password, and various strong authentication technologies can be used with both OpenID & SAML.

One resource online that really helped me frame some ideas was the Overlap of identity technologies article published on the Google OAuth & Federated Login Research site. This is an excellent summary authored by Eric Sachs, Ashish Jain, Paul Madsen. Thanks, guys.

I’m going to be giving a similar, but more authentication focused talk at CTST in New Orleans next Tuesday, May 5. Track D: Emerging Technology, D14: Smart Cards, Tokens & Digital Identity, 4:00 PM – 5:30 PM. Hope to catch some of you out there.

TrustBearer Software Gains US Government Approval

The full article is below. This is very important as it means that the TrustBearer software has been approved for use within the U.S. government. It also means that anyone with a PIV or CAC card can leverage it and use the TrustBearer OpenID and SAML service to authenticate to third party applications.


TrustBearer Desktop provides the middleware interface between the PIV compliant card and the applications utilizing the digital certificates stored on the card to perform cryptographic operations for authentication, encryption and signatures. The PIV credentials can be used for network authentication, SSL client authentication, document signatures, email signatures and encryption, virtual private networks and remote access.

“The government has recognized that critical and sensitive data must be protected using secure methods,” says TrustBearer Labs founder and CEO David Corcoran. “Hardware-based PKI authentication is widely known as the strongest form of security available. TrustBearer Labs is proud to have achieved the FIPS 201 validation for our TrustBearer Desktop product, and we look forward to serve the U.S. federal government.”

Unlike other PIV middleware, TrustBearer Desktop enables strong authentication to rich, Web 2.0 Internet applications using the government issued PIV credential through TrustBearer’s OpenID platform. Using OpenID and SAML, TrustBearer provides Single Sign-On support for online applications such as Salesforce.com, the market-leading online customer relationship management service with over 1 million subscribers, and Google Apps, a business productivity and communications platform managed by Google.

“TrustBearer not only provides the middleware to utilize PIV credentials locally on client computers, but also combines the strength of hardware-based PKI authentication with the simplicity and ease-of-use that web users expect with online applications,” says Mr. Corcoran. “This is a tremendous example of how government issued PIV credentials can be leveraged in online applications and improve both security and convenience.”

About HSPD-12 and the Approved Products List: A recent report issued by the White House Office of Management and Budget showed that over 1.5 million out of a total 5.5 million Personal Identity Verification (PIV) compliant cards have been issued in response to HSPD-12. HSPD-12 mandates all government employees and contractors to carry a secure form of identification. The GSA maintains a FIPS 201 evaluation program and provides an Approved Products List (APL) of products meeting the guidelines and technical specifications. The APL governs which products and services may be purchased by government agencies. The full list of approved products available for purchase by US government agencies can be found at http://fips201ep.cio.gov/apl.php.

About TrustBearer OpenID:
TrustBearer OpenID is a federated digital identity web platform. The service provides users with hardware-based, multi-factor authentication to websites that have implemented the OpenID or SAML standards. TrustBearer supports a variety of hardware tokens, including many smart-card based federal identity cards such as the U.S. Government PIV, CAC and TWIC cards. Sign up for a free account at https://openid.trustbearer.com.

Online web mail provider adds OpenID support

I hadn’t heard of this web mail provider until a recent blog post from their site where they discuss security options for OpenID. Thanks for the mention, LuxSci. 

Secure ID Card or USB Token: With one of these devices, you authenticate yourself by having the device in your possession and connecting it to your computer when you want to login.  This is very secure and can be combined with a password for two-factor authentication and strong hardware-based security

TrustBearer is the leading company providing OpenIDs that work with such hardware devices.  They also sell their own device.

Biometrics: Perhaps the most secure way of authenticating is the use of Biometrics.  The most common way to do this is to have a USB device which will read your fingerprint and verify it so that only you can login to your OpenID.

TrustBearer supports this.  The account is free. All you need is the fingerprint reader.

via Extreme WebMail Login Security with OpenID | LuxSci FYI.

A note on the biometrics device support: Currently, TrustBearer OpenID supports the Privaris plusID personal fingerprint reader and the Precise Biometrics 200MC & 250MC with a PIV smart card with Match-On-Card support. We’ve received a few emails about supporting the IBM/Lenovo ThinkPad fingerprint readers. We do not yet support these biometric readers.

Building on the OpenID PAPE specification

When we decided to launch our TrustBearer OpenID provider, we were excited that there was an extension to the OpenID specification that would allows us to convey the strength with which we authenticated our users. The OpenID Provider Authentication Policy Extension (PAPE) appeared to provide us with a way to tell Relying Parties (RP) that we were using arguably one of the strongest methods of user authentication available: PKI challenge-response with the user’s private key stored in a hardware device and protected by a passphrase.

PAPE allows OpenID Providers (OP) to describe their authentication policies to RPs using the following 3 categories:

  • Phishing-Resistant Authentication: An authentication mechanism where the End User does not provide a shared secret to a party potentially under the control of the Relying Party.
  • Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor.
  • Physical Multi-Factor Authentication: An authentication mechanism where the End User authenticates to the OpenID Provider by providing more than one authentication factor where at least one of the factors is a physical factor such as a hardware device or biometric.

There is some overlap between these categories, and if an OP supports more than one policy, they should all be asserted. (e.g. Using a hardware-based key with PIN would typically include all 3 of these policies)

For TrustBearer OpenID we assert all three of these policies. This would appear to say to RPs that we are providing the strongest authentication techniques available. And it does.

But there is a problem.

Many other OPs, using arguably less-strong authentication techniques could also assert the exact same policies. How? Consider the following scenarios.

Phishing-Resistant Authentication

This policy states that if a shared secret is not passed from the user to the OP, then this authentication method is considered to be phishing resistant. Does this include a password that is sent over an SSL channel? What about a one-time-password? Depending on their opinion, an OP could probably make the case that they support or don’t support phishing-resistant technology. The decision is subjective.

Multi-Factor Authentication

The policy states that the user authenticated using more than one factor (something you have, know, or are). The problem is that all kinds of multi-factor authentication are not treated equally. One OP could authenticate its users using client authentication with SSL and a password-protected private key, while another OP could use a password + visual grid card. These types of multi-factor authentication are not equivalent, but this policy could imply that they are equal.

Physical Multi-Factor Authentication

The policy states that the user authenticated using multiple factors where one of the factors is a “hardware device or biometric.” Like the multi-factor authentication case, specifying “physical” still opens a wide range of levels of authentication. A biometric device that unlocks a password that is sent to the website is far less secure than using PKI-based smart card authentication with PIN protection.

The PAPE authors intentionally avoided defining specific authentication methods. Instead, they stuck to these higher-level policies to describe classes of authentication that were used. While I understand the motivation of this decision (high-level policies change less than authentication technology), I feel that it will lead to OPs and RPs subjectively interpreting how the user was actually authenticated.

A Solution

A few members of a related industry group, the Initiative for Open Authentication (OATH), got together and discussed the PAPE specification. Together we came to the conclusion that specific assertions about how a user authenticated to an OP were needed. This group is tentatively calling our suggested changes OpenID Provider Authentication Policy Extension – Authentication Mechanisms (PAPE-AM).

Even though specific authentication methods change more often than the higher-level policies presented in PAPE, they are much more definitive. Consider the following OP response parameters presented in PAPE-AM (Note: These are all in a draft stage and have not yet been accepted by any official OpenID specification working group) :

  • method = {password, otp, pki, biometric}

    The authentication method must contain one or more of these elements in the set. We chose 4 of the most common authentication methods today. This set could be expanded in the future.

  • otp.info = {mode, token_type, consent, length, encoding, algorithm}

    This parameter contains detailed information about the type of One-Time Password token and service that was used during authentication. Consent is defined by the additional factor of authentication needed to use the OTP (such as a passphrase or biometric).

  • pki.key.info = {storage, algorithm, policy, consent}

    This parameter contains detailed information about the private key used in a challenge-response with PKI authentication. (e.g. “hardware”, “RSA_1024”, “not exportable”, “passphrase”)

Each of these response parameters are clearly defined. This gives both the OP and RP the ability to objectively assert and verify what method of authentication was used.

Who would use this? The same OpenID Providers & Relying Parties that would use PAPE. Here’s a couple use cases:

  1. Online banking website that supports government-issued ID smart cards

    Consider an online banking website that has adopted support for OpenID, but wishes to restrict access to users who have been issued a citizen ID smart card by government authorities that the bank trusts. In this case, the online banking website would use PAPE-AM to ensure hardware-based PKI authentication was used with the OP. The banking website would also use PAPE-AM to get information about who issued the user’s digital certificate.

    These additional request/response parameters provided by PAPE-AM help ensure that the bank’s users will not fall victim to hijacking attempts since client authentication using PKI with a hardware-based token was used. The information about the issuer of the certificate could help the bank prove the real-life identity of the user, also.

    By using PAPE-AM request/response parameters such as method, pki.key.storage, pki.cert.revocation_check, and pki.key.info an online bank RP could be assured that the OP is authenticating its users as described above.

  2. Online Brokerage Supports OTP

    An online brokerage supports OpenID as a RP. However, when enabling users to authenticate via third-party OpenID Providers, they want to make sure that the user is using a hardware OTP token where the length of the OTP is at least 8. The RP can request additional PAPE-AM attributes during the OpenID exchange and thereby can be assured that the user and the OpenID provider meet the requirements.

    By using PAPE-AM request/response parameters, including method and otp.info, an online brokerage RP could be assured that the OP is authenticating its users as described above.

Next Steps

I created this post because the PAPE-AM authors and I wanted to engage the community that is impacted by both PAPE and the suggested changes that I outlined above. The authors and I felt that we could help OpenID gain adoption amongst Identity Providers & Relying Parties providing secure online services by improving the existing PAPE specificaiton. We have created an early draft of a PAPE-AM specification, and are searching for the best way to publish this draft – whether it is part of PAPE or as a standalone extension.

We would like feedback from the OpenID community. Do you think the high-level PAPE policies are sufficient? Do you see value in some of the proposed PAPE-AM request/response parameters? Should the PAPE-AM policies be merged into PAPE?

Please add your comments to this post or contact me directly.

Now supporting Salesforce.com and Google Apps

Big upgrade this week: TrustBearer OpenID now supports SAML-based authentication with Google Apps and Salesforce.com. You can use you existing TrustBearer OpenID account, or create a new one. Here’s how it works:

  1. Sign-In to your TrustBearer OpenID dashboard.
  2. Click the Enable SAML checkbox and create a new association.
  3. After creating your association, click Details to download the SAML certificate that will be uploaded to Google Apps or Salesforce.com.
  4. Login to your Salesforce.com or Google Apps account using an administrative account.
  5. Enable Single Sign On and upload the certificate that you downloaded from TrustBearer OpenID.
  6. Save changes and attempt to login to your Google Apps domain.
  7. Google Apps will recognize that SSO has been enabled and will redirect your login to https://openid.trustbearer.com.
  8. Connect your device and click Proceed.
  9. After successfully verifying your PIN, TrustBearer OpenID will pass a signed assertion to Google Apps with the account username that was configured earlier.
  10. And you’re in!
We’ve also added the ability for administrators to grant access to other TrustBearer OpenID accounts to login to the same company Salesforce.com or Google Apps domain.
Create a free account and give it a try. We’re excited about this new feature and look forward to hearing your feedback.