Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
100644 217 lines (126 sloc) 13.793 kb
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
1 ================================================
2 CloudFoundry Identity Services Preface
3 ================================================
94ad737 @daleolds further minor documentation updates.
daleolds authored
5 .. attention:: This document was written in the summer of 2011. Many of the principles and goals are still valid in Dec 2011, but it has not been updated for some time.
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
7 .. contents:: Table of Contents
9 Introduction and Disclaimer
10 --------------------------------------------------
12 We have too damn many user accounts and passwords.
14 It's beyond inconvenient. It's slowing us down while causing us to lose control of our own work.
16 More significant for developers, it's too difficult to create applications that provide secure, controlled access for their users without creating yet more damn user accounts with passwords.
18 The intent of this document is to provide an overall context in which to explore a consistent and comprehensive strategy for Cloud Foundry identity services. It covers how that strategy affects developers using Cloud Foundry, the users of their applications, and the Cloud Foundry community. The strategy should specify core structures and capabilities as well as extension points for the community.
20 This document is obviously a work in progress. It's an attempt to organize and structure some initial research and ideas.
94ad737 @daleolds further minor documentation updates.
daleolds authored
22 Goals of Cloud Foundry Identity Services
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
23 ---------------------------------------------
25 There are three goals of this phase of the identity services for cloud foundry, in order of priority:
27 Provide user authentication and authorization for the Foundry platform
28 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 Developers and administrators should have secure and convenient access to the Foundry platform itself. This includes being able to use an external user account for authentication rather than storing a password in a Foundry account. Authorization for some tasks should also be able to be given to others, i.e. delegated administration.  Authorization should also be able to be revoked, causing access to be subsequently denied across the various Foundry components.
32 Access to the platform occurs through a variety of methods, including command line tools and desktop applications, so the authentication mechanism must work for these clients as well as browsers.
34 This general concept of supporting policies and roles within CloudFoundry itself is clearly needed for application developers so that they can development teams can produce, deploy and manager applications. This concept is referred to in CloudFoundry code and internal design documents as Collaboration Spaces.
94ad737 @daleolds further minor documentation updates.
daleolds authored
36 Provide identity services to Cloud Foundry applications
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39 Foundry applications need a variety of identity services, yet the services need to be provided in an easily accessible, simple manner or developers tend to implement their own simple -- often insecure and inflexible -- solutions.
41 Some identity services that should be easily available to Foundry applications:
43 * Applications should be able to simply choose from a number of external identity sources.
44 * External identity sources should be accessible via federated identity protocols with no impact on the application developer. 
45 * Applications should be able to easily connect to a user account service to store application specific data and/or passwords.
46 * For API level access, applications should be able to simply request or validate authorization tokens from the identity service without requiring access to the users password.
47 * User authentication, authorization, and account information should be able to associated with the user's session within each existing application framework.
49 All identity services should be able to support multi-tenant applications (i.e. where users within the application come from multiple identity providers).
94ad737 @daleolds further minor documentation updates.
daleolds authored
51 Apply Foundry identity services to support the Cloud Foundry community
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
52 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
54 Developers interact with the Foundry platform and with each other to form the Foundry community. The community uses tools such as git, github, wikis, mailing lists, and IRC channels, as well as accessing the Foundry platform.  The current tools often use completely disjoint user accounts, and can lack authorization controls to enable maximum openness while maintaining necessary control to insure stable progress.
56 Our Foundry Identity Services strategy should be able to be applied to the Foundry Community tools to enhance the development process. For example, we should be able to reduce friction for developers to contribute to the community in an effective and yet controlled and stable way.
58 Interestingly, this goal is effectively a use case that can be used to drive some of the requirements for the previous goals.
60 Design Principles
61 ---------------------------------------------
63 A few appropriate principles to guide the rest of the strategy, in random order:
65 Eat our own identity services
66 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 Effectively we should focus on the goal to "Provide Identity Services to Foundry Applications". Access to the Cloud Foundry itself can be seen (mostly) as access to the initial application. Likewise, using our identity services within applications to enhance the interaction of the Foundry Community can be a great use case to drive and validate requirements for the services.
70 Reusing other user accounts should be easy -- Federation should be easy
71 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 When applying the general principle of "simple things should be easy, difficult things should be possible" to an authentication service, the simplest thing should be for an app to use external, pre-existing accounts. For most simple applications this means there is less friction for new users, and more security. Creating user accounts with passwords, captchas, and email verification should be possible.
75 Identity services should be pluggable
76 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
78 One of Cloud Foundry's strengths is its support for extensible services. Wherever possible, the identity services should use this feature to support pluggable authentication and user account services.
80 Support delegation of user access from one app to another
81 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
83 Many cloud applications now, and even more in the future, will combine their internal data and processing with that of other applications and services across the Internet.
85 Web Apps running on Cloud Foundry should not have to implement an authentication UI
86 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
88 There are many types and needs implemented in numerous authentication methods: username/password, one time password (OTP) from device, smart card, OTP to phone, multi-factor, etc. Tenants within a single application will need to use different methods. To provide necessary security and flexibility, the identity provider must be able to specify the authentication UI. For web applications this is done through browser redirects.  For non-web applications, we will need to come up with something else.
90 Components and Functional Description
91 ---------------------------------------------
94 Overview
95 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
97 Overview and block diagram here showing major component and plugin points.
99 Identity Services Core
100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
102 Most important service is coordinating authentication, authorization, and account services with applications. Other possible core services:
104 * OAuth services for AuthServer, Client, ResourceServer
105 * Public key store and signing service
107 Account Services
108 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
110 Support plugin for identity account system. Account system should provide persistent storage for user information, whether or not passwords are used. Should be able to support provisioning and schema similar to SCIM. User accounts should be able to be connected to the session management system within each framework.
112 Authentication Services
113 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
115 Support plugin for authentication system. By supporting plugins we can provide direct authentication services via LDAP or Foundry account services, or federated authentication via OpenID, OAuth, or SAML, but not every application has to carry support for all authentication types.  
117 Current expectation is that this service will need to have some interaction with the application's login screen -- either by providing some javascript code to the application or redirecting to code in the framework. After that, the application uses session capabilities of the framework. 
119 Authorization Services
120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
122 Support plugin for authorization services. This would be particularly useful to call out to Horizon Access Manager.
124 Developer Perspective
125 ---------------------------------------------
128 The simple case
129 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
131 Simple case should be external identity sources such as Google Accounts, Facebook, Horizon Access Manager. Developer connects to authentication service, injects javascript snippet into login page. Done.
133 Difficult cases
134 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
136 To have more control over login sequence than the simple case, the developer will need to separate redirection to IdP from callback to get identity token. See OmniAuth.
138 Multi-tenancy, especially IdP discovery.
140 Easy registration via OpenID or OAuth, then separate accounts.
142 Support for multiple authentication sources per account.
144 Lots more variations, external authorization issues, etc.
146 End User Perspective
147 ---------------------------------------------
149 What it looks like to a user ...
151 From the browser
152 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
154 Easy case, redirection, javascript chunks, etc.
156 Options for non-browser applications
157 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
159 Some companies, e.g. Salesforce, and standardizing on launching a browser in all cases, then redirecting back to the native app using a special HTTP scheme.
161 OAuth2 supports a flow where an access code can be obtained and typed in.
163 Just an idea -- perhaps we could support an IdP specified list of named fields to collect on the command line and pass to the backend (or pass a hashed value). This would handle many cases such as username/password‚ OTP, number sent to phone, etc. The problem is that this will still ultimately fail for some authentication methods, e.g. graphical or biometric.
165 Securing Developer Access to the Foundry Platform
166 ---------------------------------------------------
168 How identity services would be applied to the cloud foundry itself.
170 Need support for non-browser native apps such as vmc. Options:
172 * like the mobile app flow‚ pop up browser and redirect
173 * if no redirect possible, oauth2 supports a flow where an access code can be obtained and typed in
174 * support username/password as a fall back -- if we can show easy, more convenient options‚
175 * perhaps just specify a list of named fields to pass to backend \-\- OTP, number sent to phone, etc
177 Supporting Collaboration within the Foundry Community
178 -------------------------------------------------------
180 How identity services could be applied to the Cloud Foundry Community itself.
182 Hypothetically speaking how these identity services could be applied to GitHub, git, irc, twitter, wiki,
184 Not hypothetically speaking, what can we do to make things better now with an evolutionary approach? Perhaps by combining some apps running on CloudFoundry, CloudFoundry itself, and integrating with some of the external collaboration systems via Horizon Access Manager.
186 Integration with Horizon Access Manager
187 ---------------------------------------------
189 Should be very simple out-of-the-box one-click integration to support for external federation system, rules engine, etc., of Horizon Access Manager.
191 Relevant Standards
192 ---------------------------------------------
94ad737 @daleolds further minor documentation updates.
daleolds authored
195 OAuth2
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
196 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
198 The OAuth 2 RFC from the IETF should be complete this summer. A number of companies such as Google, Microsoft, Facebook, Salesforce have already implemented early versions of the RFC.
94ad737 @daleolds further minor documentation updates.
daleolds authored
202 OpenID Connect
5a7c5de @daleolds revise docs to reflect ACM design, upate terms.
daleolds authored
203 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
205 OpenID has been somewhat stagnant since OpenID 2.0 was completed. The community fragmented over competing future directions in efforts such as OpenID Connect, OpenID Artifact Binding, etc. These issues appear to be resolved as of early May 2011. The combined efforts are now called OpenID Connect (though developed in the OpenID AB working group), and will be built on top of the OAuth 2 RFC.
209 Simple Cloud Identity Management (SCIM)
210 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
212 A new effort led by Salesforce, Ping Identity, others, attempting to produce a REST/JSON standard for managing user accounts, attributes, roles, groups. LDAP for cloud apps.
Something went wrong with that request. Please try again.