CTO Talk

SalesForce for Google Apps

Mon, 14 Apr 2008 19:40:06 -0600

Salesforce.com and Google have just announced a strategic partnership called “SalesForce for Google Apps”. You can read more about it here and here, but in a nutshell it means that Salesforce customers will be leveraging Google productivity and collaboration tools (such as Gmail, Google Calendar, Google Talk, and Google Docs) from directly within the SaleForce application.

Why do I care?

In a nutshell, this partnership will further highlight the need for seamless identity integration between the enterprise and their SaaS vendors, as well as seamless identity integration between the SaaS vendors themselves. By identity integration I am talking both Secure Internet SSO (Federation) as well as User Provisioning.

This is big news from a Ping Identity perspective as it aligns with our strategic vision to address the security issues that arise from the de-perimeterization of the enterprise via SaaS. While our PingFederate product already supports SSO to both SalesForce.com and Google Apps, one of the reasons for our SXIP Access acquisition was to accelerate the ability for PingFederate to also support user provisioning between the enterprise directory and the SalesForce.com and Google Apps applications. Imagine using PingFederate to automatically synchronize user accounts between your directory and both SalesForce.com and Google Apps, while also offering SSO !!!

A Model for an Internet Identity Layer

Thu, 3 Apr 2008 08:39:59 -0600

The much discussed notion of an identity meta-system is of paramount importance to addressing the issues of de-perimeterization that are facing enterprises. I have personally found the definition of this identity meta-system a little fuzzy, beyond the fact that I know it has to support multiple protocols and technologies.

Given some of my background includes coding networking protocols and doing firewall architecture I actually prefer to think of the identity meta-system as an identity layer. This layer sits between the application and the network. An interoperable, secure identity layer is vital for addressing the security and privacy requirements that can be leveraged cost effectively and securely by all organizations.

I have used the analogy of comparing this new identity layer to the old OSI layered model of network architecture. The OSI model broke the network layer into multiple sub-layers. This allowed for a consistent discussion and comparison around different networking protocols that over time included SNA, DECNET, X.25, IPX/SPX, TCP/IP etc etc. It ended up being taught in Networking 101. The fact that over a 20 year period all networks morphed to support TCP/IP is irrelevant in light of the value this model provided in allowing for consistency.

This identity layer should consist of three sub-layers – a claims sub-layer, a security token sub-layer and an identity transport sub-layer.. Each of these sub-layers are already generally included in the different standard and proprietary identity protocols that exists today. The problem I have found is that everyone tends to talk about these sub-layers only in the context and the language of the identity protocols they are endorsing.

In summary,

• The Claims Sub-Layer is responsible for conveying user information such as authentication, attributes, roles, group, authorization decisions, reputation, etc. I like Microsoft’s use of the term claim as a catch-all name for all of this identity information. It allows for an expansion of what may be considered to be identity information that needs to be shared between applications at this layer. In addition this sub-layer is responsible for mapping claims between different schema formats and name spaces.

• The Security Token Sub-Layer is responsible for conveying the security tokens that contain the claims. This can involve multiple token types such as SAML tokens, Kerberos tickets, OpenID responses as well as proprietary token types such as SiteMinder SMSession tokens. In addition this sub-layer is responsible for mapping tokens between different token formats.

• The Identity Transport Sub-Layer leverages the network to moves tokens between applications. This sub-layer includes the different SAML Web SSO Bindings, OpenID Request/Responses, WS-Security/WS-Trust for web services, and even the WS-Trust profile for InfoCards. In addition this sub-layer is responsible for routing between different identity transports when necessary.

In addition, we have found that applications developers are spending far too much time concerning themselves with the lower levels of the identity layer. App developers need to be able to leverage a standard identity API interface that interacts with the claims sub-layer. The developer should receive all the information it needs via this API directly from the claims sub-layer. This information obviously manifests as claims and as such means that application, by default, must become claims aware. Today, this likely just means user attributes or a role value, but in the future this may include actual authorization decisions. Leveraging a standard API that allows an application to plug-and–play with the identity layer offers some future proofing as the identity protocols underneath change.

Lastly is the concept of identity routing which I think is extremely important if we are to avoid every application being forced to understand the whole identity mesh. The identity router is responsible for mapping between different formats at each of the sub-layers. This could mean attribute mapping at the claims sub-layer, mapping from SAML Tokens to SMSession tokens at the Security Token sub-layer or routing between WS-Federation and SAML at the Identity Transport sub-layer. An identity router consolidates where this has to happen. Again using a networking analogy, each application/system leverages an Identity Router which becomes the Identity Layer equivalent of a ‘Default Route’. Obviously this is what I view as the role of our PingFederate product, but over time there is no reason why this Identity Router can’t be implemented as a service in the cloud.

So in summary, with apps, users and the data center becoming virtualized eneterprises must be able to support a decentralized identity infrastructure. To achieve this we think a secure, interoperable Identity Layer is paramount and that applications should be able to just plug & play with this identity layer. While the convergence of all these identity protocols on a single standard may be the ‘holy grail’, the identity layer can allow for these identity protocols to at least be implemented independently from the applications. We at Ping Identity are focused on providing the infrastructure and services to make this Identity Layer a reality.

Five Themes Driving the De-Perimeterization of the Enterprise

Wed, 2 Apr 2008 12:58:27 -0600

There are a number of significant areas that are driving a sea-change in the way enterprises must think about identity management. In a nutshell we see this need manifesting via five strategic themes.

1. Collaboration & Enterprise 2.0

Organizations will continually strive to get closer to employees, consultants, customers, suppliers and partners. This has been traditionally been phone and email, but is becoming wiki’s, blogs, portals, VOIP, presence, IM, web conferencing, and even social networks. Look what happened to email without a strong identity/security layer. Unfettered peer to peer interaction will increase significantly between users.

2. Virtualization & Cloud Computing

Corporate applications will be running on virtual infrastructure that could be located in the data center or in the cloud. The benefits associated with low cost DR and reducing internal IT costs will be some of the main business drivers. The result is that developer are unaware of where the application will be deployed and more importantly cannot rely on the ‘It’s secure because I’m behind the firewall’ mentality.

3. Master Data Management

Companies are constantly striving to know more about their customers and as such will start to use MDM to link their internal customer silos and mine the data. ‘Know your customer’ will rise to a new level to support increased opportunities to up sell additional products & services, targeted advertising, etc. Unfortunately this may also result in an increased privacy issue as it creates a bigger honey pot and is very attractive to the bad guys.

4. SaaS/On Demand Business Applications

All commoditized Enterprise applications will soon be available on-demand as an alternative to on-premise. While the aura of SaaS meaning ‘no software’ will persist for a while, enterprises will eventually drive requirements for tighter integration between different SaaS vendors via SaaS mashups (e.g. CRM and Marketing) as well as between SaaS and internal IT systems. In addition Audit & Compliance will drive IT to become more involved with their SaaS vendors in relation to meeting requirements for SOX etc.

5. Increasing Internet Crime

Internet Crime is continuously on the rise and is shifting from consumer/FI focused to B2B focused. The bad guys are happy to follow the money trail even if they have to start two or three steps removed from the money. Sophisticated attacks involving web 2.0 social engineering are going to continue to appear.

The de-perimeterization of the enterprise has arrived, but most of today’s enterprise identity management technologies are ineffective at supporting this new decentralized infrastructure. The question becomes, how do you retain cost-effective control and keep the ’bad guys’ out when applications, users and the data center are becoming virtual with access from anywhere at anytime.

In my next post I will share our vision for how the Identity Meta-System and more specifically an identity layer (that supports distributed identity management) is a business imperative and can provide the framework for a decentralized identity infrastructure that can be leveraged cost effectively and securely by all organizations.

Dynamic SAML Article in IEEE Security & Privacy

Mon, 31 Mar 2008 20:16:28 -0600

The IEEE Security and Privacy magazine just published an article I co-wrote with Nate Klingenstein and Leif Johansson on Dynamic SAML and how it can be used to simplify SAML deployments. Nate and Leif are two extremely knowledgeable federation and security experts who hail from the Shibboleth community. You can read the article online without a subscription here.

It was both interesting and enlightening to work with Nate and Leif on this article as they brought an alternate perspective from the Shibboleth world as to why Dynamic SAML will be beneficial to Shibboleth federation communities. The article became an intersection of our combined ideas on how automating the exchange of SAML configuration information (meta-data) can lead to simpler SAML deployments.

Dynamic SAML is also the foundation of our Auto-Connect capability in PingFederate 5.0. Auto-Connect includes some additional optimizations that we felt would further simplify SAML deployments. One example of this is the requirement to use the simpler front-channel Browser POST and Redirect bindings. Nate, Leif and I discussed the merits of including this and other Auto-Connect optimizations in Dynamic SAML, but decided to leave them out and treat them as deployment best practices and conventions. During this exchange, one of my favorite quotes came from Nate who succinctly said - "I think back channel's dead". Sort of sums up my view of the SAML Artifact binding.

Adoption and State of the Federation Market

Mon, 3 Mar 2008 13:14:14 -0700

I was recently asked to participate in a Burton Group podcast with Sun and Covisint on the 'Adoption and State of the Federation Market'. Gerry Gebel did a great job moderating the discussion. The synopsis is below. I think you will find its a worthwhile 20 minute listen.

"In January 2008, Burton Group published a report evaluating products in the Federation technology market. Federation is an important tool for deploying cross-domain sign-on and access solutions. With more than a dozen products on the market today, information technology (IT) architects have no shortage of options. Because large organizations require a tiered model for federation, few will be able to settle on a single federation server or hosted provider for all their federation needs. Most organizations will deploy a mix of general-purpose, application-specific, and open source technologies to round out federated identity.
In this Burton Group Tech Watch podcast, Gerry Gebel moderates a discussion on the adoption and state of the federation market with providers: Ping Identity, Covisint and Sun."

SAML Bindings Best Practices

Thu, 28 Feb 2008 11:30:58 -0700

The majority of SAML deployments we see are standardizing on the front-channel HTTP POST and HTTP Redirect bindings for SSO and SLO. These bindings are proving to be much simpler to implement than the bindings that require back channel communications.

Why is this?

The use of SAML bindings that require back channel communication (e.g. SAML Artifact and SAML SOAP bindings) are inherently more complex to deploy. We have masked a significant amount of this complexity within PingFederate but there are still a number of deployment considerations that always end up being tricky. Most obvious is the need to establish a secure direct communication path between the IdP and SP federation servers. This likely involves negotiating some transport level authentication mechanisms (above and beyond SAML message signatures), opening the appropriate firewall ports to allow requests/responses between servers, implementing proxy servers or web service gateways, again to allow connectivity through the DMZ, etc. This additional complexity comes without any real material advantages that make the extra complexity worthwhile.

For example, the Artifact Binding is no more or less secure than the POST Binding as it relates to message replay attacks. The main reason for the existence of the Artifact Binding was to actually have an option in SAML 1.x SSO where SP’s did not have to validate XML Digital Signatures over each SAML Assertion. The Artifact Binding allowed the signature to be optional, and instead allowed the deployer to leverage transport level security. It was felt that this offered a simpler implementation option for SP’s. The SOAP Binding was actually introduced as a performance optimization for SLO, as opposed to having an IdP redirect the browser to every SP to indicate a Logout had occurred. To leverage SOAP SLO each SP is required to track local user session state in some backend database so that the user session can be cancelled (logged out) without the browser being present. Common practice among SP’s seems to be to maintain user session state in a browser cookie which requires the browser to be present. As such SOAP SLO has seen very limited use.

New SAML deployments should take advantage of lessons learned from past experience and avoid the back channel bindings. It is much more likely that your federation project will run more smoothly if you do. This is also why we chose to target the front-channel bindings for Auto-Connect.

PKI and SAML - Friends or Foes

Thu, 14 Feb 2008 07:51:01 -0700

One of the reasons that SAML based Federation exists is that wide-spread use of user certificates never materialized. If it had, then it is unlikely that SAML would be what it is today as user certificates themselves can securely solve the cross-domain web SSO problem.

That said, there have been some industries that have been willing to invest the money to make PKI work at scale for large user communities. As such we at Ping have struggled to justify the value of SAML in these entrenched PKI communities that already rely on user digital certificates for authentication and cross-domain web SSO.

We have been recently discussing with a number of these communities a security architecture where federation is useful in addition to user certificates. In this architecture SAML Assertions are used solely for authorization purposes rather than for the more generally accepted purpose of authentication/SSO. Their issue is that digital certificates are not well suited for conveying directory based attribute information, such as user role and group designations, that is used for making authorization decisions. These user attributes can change over relatively short periods of time. While they will continue to authenticate users and systems with certificates, they plan to leverage SAML Assertions to communicate user attributes between applications in different domains. These attributes will be used to make authorization decisions.

For example, if a user from Domain A turns up at an application in Domain B they will be authenticated by that application with their cert as usual. But the application in Domain B needs certain user attributes to make authorization decisions that are in the directory in Domain A. SAML Web SSO is used to request a SAML Assertion from Domain A that contains the necessary user attributes. The user will also be required to authenticate to Domain A with their certificate before the SAML Assertion is made available to Domain B.

This security architecture supports a decentralized identity infrastructure rather than requiring a centralized directory infrastructure. It also alleviates the need for directory synchronization between domains. While the back channel SAML Attribute Query/Response protocols could also be used for retrieving SAML Assertions, there are significantly greater deployment headaches associated with setting up SOAP based back channel bindings. The front channel, browser based POST/Redirect bindings are much simpler to deploy. The SAML Assertion and the attributes themselves are integrity protected via an XML Signature, and optionally can be kept confidential with the use of XML Encryption.

Trusting SAML Meta-Data

Wed, 30 Jan 2008 10:17:18 -0700

We announced the release of PingFederate 5 this month. This release includes support for dynamic federation which our marketing department has called Auto-Connect(tm). One of the more interesting aspects of Auto-Connect is how you establish the trust that allows you to know that the business partner you are federating with is really who they say they are. Andre touched on this a little bit here.

Before Auto-Connect an organization had to establish a cryptographic trust relationship with its partner via the manual, out-of-band exchange of certificates. This means the each organization ends up with a list of partner certificates that anchors the trust relationships – a trust anchor list. The SP only accepts SAML assertions from an IdP if the signature over the SAML assertion can be validated by a certificate in its trust anchor list. The need for this out-of-band exchange of certificates is one of the friction points we are eliminating with Auto-Connect.

An additional issue is that as a company starts to federate with more and more federation partners the number of partner certificates they must manage increases. As we all know, certificates expire and quite often need to be renewed as often as every 12 months. I have been involved in a number of situations where an application failure is the result of an expired certificate. Once an organizations trust anchor list contains 10's and 100's of partner certificates, a different partner certificate will expire weekly or even daily. Organizations are then forced to add people and process to track certificates that are about to expire, reach out to their partners for a new certificate and then test that the new certificate actually works. Ouch. Trust me, I've been there.

One of the benefits of Auto-Connect is that the partner certificates used to sign and validate SAML Assertions are included in the SAML meta-data file. In addition every partner’s SAML meta-data file is dynamically retrieved by the federation server from a well known URL endpoint. The SAML meta-data file includes controls around cache-duration and meta-data validity periods that allow each partner to dynamically control when a partners federation server should re-retrieve meta-data and thus get a new certificate. This may be set to daily, weekly or monthly depending on how often the contents of the meta-data file is expected to change.

The fact that you trust the key in the meta-data and will use it to validate signatures of SAML messages is because you have separately established trust in the meta-data file itself. So obviously this begs the question – How do I trust the meta-data file is my partners meta-data file?

The short answer is that the meta-data file itself must be signed and the X.509 certificate used to validate the signature is itself included in the meta-data file. The keys used to trust the meta-data file are separate and in my view will be X.509 certificates issued by publicly trusted Certificate Authorities. The trust anchor list in each partners federation server will contain root CA certificates rather than individual partner certificates.

In effect we are leveraging dynamic SAML meta-data retrieval to facilitate key distribution. Obviously this is all happening under the covers and the user and the federation administrator see all of this happening transparently.

Identity Portability as a Key Enabler for Virtualization

Mon, 17 Dec 2007 14:51:32 -0700

I was recently asked for my thoughts on whether identity portability and identity standards were a key enabler for virtualization. I was also then sent a link to an article about how a lack of industry standards may threaten virtualizations growth.

From my perspective choosing to leverage virtualization is currently a system operations driven decision. I seriously doubt that in today’s virtualization world, application functionality such as authentication and authorization is a major consideration when choosing whether to leverage virtualization technology.

Identity becomes important when organizations start to take advantage of outsourced virtualization (e.g. Amazon’s EC2). It is highly unlikely that an application designed for use inside the company will be able to be seamlessly migrated to an outsourced virtual machine running on Internet facing hardware. Achieving this virtualization independence will require that an application can be run on a local or remote virtual machine without change. This means that any authentication related application functionality must be secure, loosely coupled and standards based. The developer should not be baking authentication functionality directly into the application as he won’t know where his application is being deployed. As such standards based, secure SSO becomes paramount.

Malware as a Service

Wed, 12 Dec 2007 21:58:33 -0700

We held a webinar (listen here) this morning on how federation can help reduce the likelihood of succesful phishing attacks against the enterprise SaaS market. I think this article in CIO magazine is extremely pertinent. This is fascinating reading with a bunch of equally fascinating follow up articles. I actually incorporated some of this information into my webinar material.

Can Federation help solve the SaaS phishing issue?

Fri, 30 Nov 2007 14:01:12 -0700

Most people are aware of the recent security issues that SalesForce.com are facing as a result of the successful phishing attacks against them (more here). I am expecting that this will be the straw that finally breaks the back of the SaaS market as they come to understand that secure internet SSO via federation is not a ‘nice to have’ but a ‘must have’.

One of the attack vectors that make a phishing attack possible is a public web form available on the internet that collects user credentials. Phishers make a look-alike form and get a user to submit their real credentials to the fake form and then take those credentials and submit them to the real form to get access to the phished users data.

IdP initiated federated SSO eliminates the need to put a web form out on the internet to collect credentials. In this model credentials are collected at an internal enterprise site and then federated over to the SaaS vendor - so there is no public web form to use to trick users. Generally speaking in this model the user always accesses the SaaS provider from a link on their corporate intranet portal.

From discussions we have had with a number of different SaaS vendors we have realized that IdP-initiated federation is too restrictive. These SaaS vendors want to support roaming users who may not be always connected to the company intranet (e.g. the salesforce), as well as access from ‘deep’ links such as bookmarks or URL’s contained with email messages.

This is where SP-initiated federation (optionally using email address based IdP discovery) comes into play. In this model an unauthenticated user can start at the SaaS provider, be redirected to their corporation for authentication and then be returned to the SaaS application with a SAML token that gives them access. SaaS customers will have to make their employee authentication service available on the Internet much like they do with employee remote access. In this case the risk of phishing attacks against a specific SaaS vendor is distributed across their customer base. Every organization’s externally facing login web form will be different and can even incorporate stronger authentication as necessary. In the future I imagine that a SaaS customer could even go one step further and outsource their authentication process to a SaaS provider specializing in strong authentication and identity verification.

One last area of feedback we have received is in relation to SaaS plugins for desktop software such as mail, calendar, browsers and IDE’s. The use of these plugins also requires authentication and generally means the use of a password that is quite often cached in the plugin after first use. SaaS providers don’t consider federation to be providing the whole solution until these plug-ins are also supported. Fortunately the SAML 2.0 specification includes the ECP (Enhanced Client/Proxy) SSO profile that can be used to address this problem. I will blog more about how we are planning to use ECP to solve this specific use case.

As far as I can tell there should be no reason that every SaaS provider should not be striving to eliminate passwords from their environment entirely. As can be seen by the issues Salesforce.com is currently facing, the cost and risk of supporting user passwords has risen significantly and will continue to do so. From a SaaS perspective, our goal at Ping is to make Federation so easy and cost effective to setup and administer that it is not worth looking at any other alternative authentication scheme.

Dynamic Federation - Under the Covers

Tue, 27 Nov 2007 08:33:06 -0700

This morning Andre posted some high level details on our company blog (here) around how to automate federation connectivity via what we are calling dynamic federation. I thought it would be helpful to dig a little deeper and describe how we see this working under the covers.

It is important to note that nothing defined below is proprietary and that everything is already specified in the SAML 2.0 speciification. For this to succeed we are proposing that two conventions be adopted. The first is for the optional use of email address to bootstrap IdP Discovery for SP-Initiated SSO. The second is to standardize on an EntityID URL format that can be derived from a domain name (i.e. abc.com maps to a SAML entirity id of https://saml.abc.com). Here is a sample message flow.

1. User attempts to access a resource at the SP and is prompted for their email address as an identifier (this is likely their corporate email address).

2. User is redirected to the SP federation server with domain name as a query parameter.

3. SP federation server checks domain name against white list to determine if this is a trusted SSO-enabled IdP.

4. SP federation server retrieves and caches signed meta-data file from IdP at the URL expressed by the IdP’s entityid - http://saml.idp-domain-name.com. The metadata contains the IdP's certificate, the SSO Service endpoint and optionally single logout endpoints. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the IdP matches the signing certificate DN.

5. SP federation server redirects user to IdP SSO URL with signed AuthNRequest.

6. IdP federation server checks white list using domain name from Issuer field in AuthNRequest.

7. IdP federation server validates the AuthNRequest. The federation server retrieves and caches signed metadata file from SP at the URL expressed by the SP’s entityid - http://saml.sp-domain-name.com. The metadata contains the SP's certificate, the Assertion Consumer Service endpoint and optionally single logout endpoints and attribute requirements. The federation server verifies the meta-data signature and ensures that the attached certificate is valid. The federation server validates that the domain name of the SP matches the signing certificate DN.

8. IdP authenticates user.

9. IdP federation server creates SAML Assertion containing users email address (and other optional attributes) and uses the SAML Post Binding to redirect the user back to the SP.

10. SP federation server validates the SAML Assertion (including verifying the signature over SAML Response) and checks its white list using the domain name from the Issuer field in the SAML Response.

11. The SP generates the local session cookie and redirects the browser to the requested resource.

User-Centric Identity Within the Enterprise

Mon, 19 Nov 2007 15:05:43 -0700

I have been asked on a number of occasions for my thoughts on how user-centric identity can apply to employees within the enterprise. This is usually just a poorly disguised technology question (i.e. what are CardSpace and OpenID). On occasion I have had to take this further and explore peoples varying definitions of user-centric identity and relate that back to an enterprise employee setting. There are valuable things some enterprises will do with user centric identity for their customers, but trying to put user-centric identity concepts entirely within an enterprise setting feels like a bit of a stretch in the near-term.

• User centric implies user control. This is in many cases the inverse of what most enterprises want, but not to say that there aren’t scenarios where a new approach will not add value.

• User centric implies self asserted information. Enterprises already know everything they care to know about their employee. With the exception that it’s possible that a third party could attest to a user identity maintained in the cloud or on some keyfob, and that user could bring that identity into the enterprise when they are hired on as an employee or contractor. But we’re a ways off from a robust enough ecosystem and trust model to support this in mass.

• User centric implies user choice of identity provider. Within the enterprise, HR and Active Directory are the authoritative IdP, and the enterprise likes it that way. While the enterprise might allow their employee identities to be used outside of their company that identity will no doubt be contingent upon employment. In 99.9% of cases today, the employee does not get a choice of IdP, and that’s not likely to change anytime soon. Investments in employee strong authentication will only further centralize this point.

• User centric implies simplicity and SSO. The enterprise has been trying to solve this for 20 years with Kerberos, E-SSO, SPNEGO, WAM and SAML. While there are a few new themes with user-centric scenarios, I don’t believe anyone thinks that there is a new silver bullet here.

• User centric implies identity for Web 2,0. The enterprise is going there, but web 2.0 enterprise products will be forced to integrate with the existing identity/security infrastructure inside the enterprise. I don’t think Web 2.0 will drive Identity 2.0 inside the enterprise.

• User centric implies user privacy. This is one area where enterprises may look to defer liability/risk/cost associated with protecting personal employee information.

Humble Beginnings

Wed, 31 Oct 2007 13:01:55 -0600

Andre has finally talked me into maintaining my own blog. For better or worse the blogosphere is now stuck with me. My goal is to make sure there is a practical aspect to this blog rather than a bunch of nebulous theorizing. In the event that I am forced down the path of pontification I will promise to at least warn people up front. Further, my intent is that this blog will not only prove to be useful for our customers and prospects, but also to our competitors and partners.