Patrick,
thanks for the submission. Submissions are not final. You are free
to revise content over time. :)
Regards,
Anil
On 07/08/2010 09:16 AM, Patrick Harding wrote:
> On Thu, Jul 8, 2010 at 10:14 AM, Patrick Harding
> <>wrote:
>
>
>> > All,
>> > Wanted to share some use cases that I think it important for the TC to
>> > address. This is a high level dump that I am happy to discuss in more detail
>> > on the call. Some of these may already be addressed to some extent by other
>> > proposals.
>> >
>> > Assumptions:
>> >
>> > I am lumping SaaS, PaaS and IaaS applications together when I think of
>> > cloud applications. I also believe that for the purposes of this TC the
>> > customer of these cloud applications is the enterprise rather than the
>> > consumer. I also believe we need to consider situations where an enterprise
>> > has 1000's of applications distributed across multiple cloud vendors, with a
>> > mix of SaaS, PaaS and IaaS. Further there are multiple user constituents
>> > that impact these use cases. I generally break these into three groups -
>> > workforce (employees/contractors), partners (vendors, suppliers, franchises,
>> > distributors, etc) and lastly customers.
>> >
>> > Use Cases:
>> >
>> > Generally speaking I see three basic use cases for cloud identity:
>> >
>> > 1. Workforce
>> >
>> > The Enterprise is making certain productivity applications available to its
>> > employees and workforce such as CRM and Mail via the cloud. In this case we
>> > are assuming that the Enterprise is the authoritative source of identity for
>> > its workforce and that this authoritative source (i.e. the directory) may
>> > be on-premise or itself in the cloud.
>> >
>> > 2. Business Partners
>> >
>> > The Enterprise is making certain applications available to its business
>> > partners for the purposes of collaboration. These applications may be
>> > maintained on-premise or be running in the cloud. In this case the
>> > enterprise wants to push the management of a business partners identity (and
>> > associated credentials) back onto the business partner. Again, we have to
>> > consider the fact that the authoritative source of identity for the
>> > business partners users (i.e. the directory) may be managed on-premise by
>> > the or hosted in the cloud.
>> >
>> > 3. Customers
>> >
>> > In this case we are assuming that an enterprises has customers that are
>> > requesting that they have seamless access (i.e. SSO) into the enterprises
>> > customer-facing applications. This could be for the employees of an
>> > institutional customer (i.e. users accessing 401K, Benefits, Payroll,
>> > etc). Alternatively it could be consumers who wish to leverage an existing
>> > consumer account such as FaceBook or Google to enable access into the
>> > enterprises customer-facing application. These customer facing applications
>> > may be running on-premise or themselves be deployed in the cloud.
>> >
>> > Across these three use cases I see the need to address 4 different
>> > scenarios:
>> >
>> >
>> > 1. Authentication& SSO
>> >
>> >
>> > 2. Account Management
>> >
>> >
>> > 3. API SSO& Security
>> >
>> > 4. Audit
>> >
>> > 5. Authorization& Access Control
>> >
>> > Goals:
>> >
>> > There are a couple of goals I am looking to achieve via the TC. First is to
>> > drive down the number of passwords that are stored and used in the cloud
>> > down to as few as possible. Second is to eliminate the need to implement a
>> > cloud version of 'directory synchronisation' where we attempt to keep
>> > identity stores in synch via traditional backchannel techniques. Third and
>> > last is to drive towards a claims based architecture wherever possible.
>> >
