Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

further minor documentation updates.

Change-Id: I0068e74beb50269ee47164ac23ab5e4a8ce6451f
  • Loading branch information...
commit 94ad7375fc739021f9f1ac4ca72643bf32cc4920 1 parent e731ab8
@daleolds daleolds authored
View
98 docs/CF-Identity-Services-Preface.rst
@@ -2,8 +2,7 @@
CloudFoundry Identity Services Preface
================================================
-.. 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.
+.. 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.
.. contents:: Table of Contents
@@ -20,7 +19,7 @@ The intent of this document is to provide an overall context in which to explore
This document is obviously a work in progress. It's an attempt to organize and structure some initial research and ideas.
-Goals of Foundry Identity Services
+Goals of Cloud Foundry Identity Services
---------------------------------------------
There are three goals of this phase of the identity services for cloud foundry, in order of priority:
@@ -34,7 +33,7 @@ Access to the platform occurs through a variety of methods, including command li
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.
-Provide identity services to Foundry applications
+Provide identity services to Cloud Foundry applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
@@ -49,16 +48,7 @@ Some identity services that should be easily available to Foundry applications:
All identity services should be able to support multi-tenant applications (i.e. where users within the application come from multiple identity providers).
-Note on Multi-Tenancy
-++++++++++++++++++++++
-
-I have seen in some Cloud Foundry documentation and heard in numerous presentations that a single DEA can support single or multiple tenants, i.e. multiple apps on a single VM. In this document I mean something else. When I refer to multi-tenancy, I mean users from multiple organizations accessing a single application. In this usage, a tenant maps to a company or department using a particular SaaS application. A multi-tenant application is one that supports multiple such organizations. All users in an organization map to tenant entity, which is usually billable, and a set of user accounts within that tenant. The accounts are sometimes external to the application but all users for a tenant generally come from a single identity provider. Think of Salesforce, Workday, and Axiom as multi-tenant applications where vmware is a tenant. For more on this definition of Multi-tenancy see:
-
-http://en.wikipedia.org/wiki/Multi-tenancy
-
-http://code.google.com/appengine/docs/java/multitenancy/overview.html
-
-Apply Foundry identity services to support the Foundry community
+Apply Foundry identity services to support the Cloud Foundry community
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
@@ -202,14 +192,14 @@ Relevant Standards
---------------------------------------------
-OAuth
+OAuth2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
http://oauth.net/2/
-OpenID
+OpenID Connect
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
@@ -223,80 +213,4 @@ A new effort led by Salesforce, Ping Identity, others, attempting to produce a R
http://www.simplecloud.info/
-Traditional OASIS federation protocols (SAML, WS-Fed, WS-Trust)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Need to support these for vast majority of enterprise federation products, Horizon Access Manager, etc.
-
-Lessons from Other PaaS and IDaaS projects
----------------------------------------------
-
-
-MyOneLogin and Horizon Access Manager
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-They both provide lessons learned, and they are primary identity services to support.
-
-Microsoft Azure Access Control Service (ACS)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-ACS 2.0 certainly covers a lot of the same topics and services, though is often a good counter example regarding how the focus on difficult cases keeps adoption low.
-
-Google App Engine and Google Accounts
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Rather simplistic in the platform -- the simple cases are handled well, but the difficult cases are REALLY difficult.
-
-Salesforce and force.com
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Need more research here. We have an outstanding invitation from the Salesforce identity team to meet and collaborate beyond current vmforce project.
-
-Janrain Engage (formerly RPX)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A separate service which offloads authentication services from web applications. Simple to use for an app, but requires apps to make external calls to yet another service. Similar to MyOneLogin and Google's new RP enablement service (called from their Identity Toolkit).
-
-Multi-factor authentication to Google App Engine
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Google supports two-factor authentication by allowing users to use a one-time password sent to a mobile phone in addition to their password.
-
-http://www.infosecurity-us.com/view/15887/twofactor-authentication-for-google-accounts-goes-live/
-
-As of late March, 2011, it was not cleanly supported by the command line tools:
-
-http://code.google.com/p/googleappengine/issues/detail?id=4777
-
-Interestingly, we could perhaps support it in Cloud Foundry similar to how it can be used to provide two-factor authentication to SSH sessions:
-
-http://www.techrepublic.com/blog/opensource/two-factor-ssh-authentication-via-google-secures-linux-logins/2607
-
-Multi-factor authentication to Amazon Web Services
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Amazon has supported multi factor authentication to AWS since 2009, though it requires a user to buy a device from Gemalto:
-
-http://aws.amazon.com/mfa/
-
-As far as I can decipher from the follow page, Amazon's multifactor authentication is limited to the AWS console:
-
-http://docs.amazonwebservices.com/AWSSecurityCredentials/1.0/AboutAWSCredentials.html
-
-Potential Starting Projects
----------------------------------------------
-
-
-OmniAuth
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Looks like a good start for authentication services for Ruby frameworks, though somewhat sparsely supported. Also, it does not appear to support multi-tenancy.
-
-https://github.com/intridea/omniauth/wiki
-
-The unfortunately named Google Identity Toolkit
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First announced at IIW (May 4, 2011), Googles Toolkit to enable web applications to support federated authentication including current best practices for login UI.
-https://sites.google.com/site/gitooldocs/
View
5 docs/UAA-CC-ACM-VMC-Interactions.rst
@@ -199,7 +199,6 @@ Web sequence diagrams for various operations
#. `vmc create org <diagrams/flow-create-org.png>`_ -- (`text <diagrams/flow-create-org.txt>`__)
#. `vmc add permissions <diagrams/flow-add-permissions.png>`_ -- (`text <diagrams/flow-add-permissions.txt>`__)
#. `vmc bind service <diagrams/flow-bind-service.png>`_ -- (`text <diagrams/flow-bind-service.txt>`__)
-#. `bosh add stem_cell <diagrams/flow-bosh-add-stem.png>`_ -- (`text <diagrams/flow-bosh-add-stem.txt>`__)
Web Application Flows
======================================
@@ -221,5 +220,5 @@ Open Issues
* New LDAP user -- expect UAA to be able to provide Just In Time provisioning, i.e. create an account as the user authenticates.
* Design database user account migration
-* we have now allowed for multiple UAAs per CC/BOSH, but we should also support multiple CC/BOSH per UAA -- and should get single signon between them. Really need a refresh token. Need to consider OAuth2 authcode flow vs. implicit flow (as Dave has suggested).
-* Need more info on BOSH model. Doesn't need Orgs, but has similar concepts of group/project, object/resource. BOSH could actually be an org within a CS instance also used by CC -- though more likely would want the separation of their own instance.
+* we have now allowed for multiple UAAs per CC, but we should also support multiple CC per UAA -- and should get single signon between them. Really need a refresh token. Need to consider OAuth2 authcode flow vs. implicit flow (as Dave has suggested).
+
View
15 docs/UAA-Overview.rst
@@ -63,24 +63,24 @@ The current applications under consideration for the authentication service with
api.cloudfoundry.com
---------------------
-The cloud foundry service itself would the UAA service. The OAuth access token would be used instead of the current token in a similar way. Possible APIs and component boundaries between the UAA, the colloboration spaces authorization system, and the cloud controller are currently being explored in POC code.
+The cloud foundry service itself would use the UAA service. The OAuth access token would be used instead of the current token in a similar way. Possible APIs and component boundaries between the UAA, the colloboration spaces authorization system, and the cloud controller are currently being explored in POC code.
www.cloudfoundry.com
----------------------
-Work with Scott Andrews to synchronize plans. Current thought is that the www site could be the UI for the user account and authentication service. It would support user account creation and management such as password reset, etc. This is also where any OAuth2 authorization page would go if we were to allow users to authorize other applications to access portions (scopes) of the cloudfoundry APIs on their behalf.\\
+Current thought is that the www site could be the UI for the user account and authentication service. It would support user account creation and management such as password reset, etc. This is also where any OAuth2 authorization page would go if we were to allow users to authorize other applications to access portions (scopes) of the cloudfoundry APIs on their behalf.
The www app also supports the microcloud DNS management which would need to support OAuth2 access tokens as a client of the UAA.
studio.cloudfoundry.com
-------------------------
-Primary point of contact so far with the CF Studio (WaveMaker) team has been Christian Dupuis. My understanding from a meeting with Christian is that the CF Studio does not hold any user account information but will pushes applications to cloudfoundry.com similar to how the vmc and STS applications do now. Since CF Studio is a web application, it can use the OAuth2 redirect flows and therefore get an access token for its users via SSO with the UAA. Current expectation is that it would not be difficult for them to implement an OAuth client in their application such that their users would get SSO with VMware applications on cloudfoundry.com.
+Since CF Studio is a web application, it can use the OAuth2 redirect flows and therefore get an access token for its users via SSO with the UAA. Current expectation is that it would not be difficult for them to implement an OAuth client in their application such that their users would get SSO with VMware applications on cloudfoundry.com.
support.cloudfoundry.com
--------------------------
-This appears to be a zendesk instance. The zendesk product already supports various flavors of OpenID and OAuth, though status of OpenID Connect support is unknown.
+The product already supports various flavors of OpenID and OAuth, though status of OpenID Connect support is unknown.
Unresolved Issues
===================
@@ -90,15 +90,10 @@ OAuth2 Scopes
Not so much unresolved as just postponed. OAuth2 lets an authorization provider designate scopes that can further restrict what access a user delegates. For example, when I here of a new app that can analyze my apps on cloud foundry, I may only want to authorize it to read my data, not make any changes.
-Interaction Between Collaboration Spaces and Authentication Services
-----------------------------------------------------------------------
-
-In Collaboration Spaces, an Org may specify the authentication policy -- ie.g. an Org may require multi-factor authentication to change production apps. When a user contacts a service, the collaboration spaces model must indicate it's authentication policy to the UAA. This is similar to the Provider Authentication Policy Extension (PAPE) in OpenID 2.0, we'll need to figure out how to accomplish the same thing in OAuth2.
-
Interaction between Collaboration Spaces and External Groups used for Authorization
------------------------------------------------------------------------------------
-In the collaboration spaces design, group may indicate that their membership is determined by an external source, such as a Group in Active Directory or a dynamic group in Horizon App Manager (which would be part of a SAML assertion). How is that information gathered by the UAA and provided to the Collaboration Spaces code?
+In the collaboration spaces design, a group may indicate that its membership is determined by an external source, such as a Group in Active Directory or a dynamic group in Horizon App Manager (which would be part of a SAML assertion). How is that information gathered by the UAA and provided to the Collaboration Spaces code?
One or More External Authentication Mechanisms for Users
----------------------------------------------------------------------
View
BIN  docs/diagrams/flow-bosh-add-stem.png
Deleted file not rendered
View
20 docs/diagrams/flow-bosh-add-stem.txt
@@ -1,20 +0,0 @@
-participant cli
-participant dir
-participant acm
-
-cli->dir: push_stem(token, context, name)
-note over dir:
- The dir must validate the token and extract
- the userID, then it translates the context
- into an objectID. The dir also defined what
- permission is required to push a stem
- cell, e.g. 'push_stem'.
-end note
-dir->acm: check_permissions(objectID, userID, 'push_stem')
-note over acm:
- read user's groups, check ACL on object
- for 'push_stem' for userID or any groupID
-end note
-acm->dir: yes/no
-note over dir: if yes, add stem cell
-dir->cli:
Please sign in to comment.
Something went wrong with that request. Please try again.