New identity and security capabilities leveraging open standards are coming to Cloud Foundry. This is the first post in an Identity and Security series describing the new capabilities that will be incrementally introduced to the Cloud Foundry open source project and later on the CloudFoundry.com service.
Cloud Foundry is committed to the Open PaaS philosophy; therefore we are implementing these capabilities using open standards such as OAuth 2.0, OpenID Connect, and Simple Cloud Identity Management (SCIM). We believe these open standards will make it even easier for partners to participate in the Cloud Foundry ecosystem and build new capabilities that benefit Cloud Foundry users. We also believe these standards will become increasingly important for interoperability with existing identity and security infrastructure.
Delegated Authorizations using OAuth 2.0
When OAuth endpoints become available on Cloud Foundry, Single-Sign-On (SSO) and delegated authorization capabilities will be available for integrations with partner applications. For example, if a partner application wants to validate a Cloud Foundry user from someone accessing their application via a web browser, the application can initiate an OAuth flow with Cloud Foundry, which allows the user to decide whether Cloud Foundry should share their identity with the requesting application. Beyond simple identification, a Cloud Foundry user can delegate specific account permissions to an OAuth enabled 3rd party application without directly providing their password to the 3rd party application. This will enable creative functionality such as enabling applications in the cloudfoundry ecosystem to simplify application provisioning by asking a user’s permission to automatically deploy and configure an application to user’s Cloud Foundry account. Another example might be delegating application monitoring to a partner with permission to retrieve application log files. Many facebook and twitter users are likely familiar with OAuth when using 3rd party applications to perform actions to their account on their behalf such as tweeting or posting to their wall, which is typically handled via a series of browser redirects. A Twitter FAQ simply states “OAuth is an authentication protocol that allows users to approve applications to act on their behalf without sharing their password.” Before OAuth, it was common for 3rd party applications to ask for and for users to provide account passwords directly to the 3rd party. Sharing account passwords gives the 3rd party total control of user accounts and is a security issue if the 3rd party is not trustworthy or stores user credentials insecurely. With OAuth, users never have to provide a 3rd party with their account password and users can delegate specific permissions to a 3rd party instead of implicitly granting all actions for an account. OAuth support will help accelerate the growth of an ecosystem of tools and applications for Cloud Foundry.
Federated Identity with Open Standards
Federated identity support will allow Cloud Foundry users to utilize existing identity providers to assert their identity or leverage Cloud Foundry as an OpenID Connect provider. Many email providers such as Google, AOL, Windows Live and Yahoo have made it possible to use your email account as your identity to a 3rd party. Additionally, many types of internally deployed identity stores such as LDAP and Active Directory can also be used as an identity provider. This streamlines the new user registration process and improves security. Just as with OAuth 2.0 for delegated authorization, users do not supply their email password directly to the third party site (Cloud Foundry in this case), but only to their trusted identity provider, which then asserts the user identity to the 3rd party.
Simple Cloud Identity Management
According to the Simple Cloud Identity Management (SCIM) scenarios, “The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier.” Essentially SCIM standardizes a mechanism for users and groups to stay in sync between service providers and service subscribers. For example, when users join, leave a organization or change roles, SCIM standardizes a way of creating, retrieving, updating and deleting users and groups with service providers that maintain a separate identity store outside the organization. For example, consider a fictitious Acme Org that maintains an internal LDAP directory and also uses Cloud Foundry. As part of Acme’s new user provisioning process they could create a new LDAP user in the internal Acme LDAP and also issue a SCIM compliant REST API call that is an HTTP POST with a JSON payload containing the new user information to the Cloud Foundry SCIM endpoint, which would provision the user on Cloud Foundry as well. We will continue following the SCIM specification as it evolves.
Source Code and Availability
The new Cloud Foundry component implementing these standards is called User Account and Authentication (UAA) and the source code and documentation is available now as a top-level project at github.com/cloudfoundry/uaa. The UAA will be updated and evolved in the open source repository and the functionality will be rolled out gradually on cloudfoundry.com. As features from the cloudfoundry.com version of UAA become available, there will be subsequent posts covering the functionality in more detail. The next post in this Identity and Security Series will cover how 3rd parties and Cloud Foundry users can leverage the delegated authorization flow. Support for these open standards for identity and security are essential for interoperability and further demonstrates the Cloud Foundry commitment to an Open PaaS.
– The Cloud Foundry Team
Don’t have a Cloud Foundry account yet? Sign up for free today