Re: [id-cloud] Re: Use Cases

[Anil Saldhana <Anil.Saldhana@redhat.com>]

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
> <pharding@pingidentity.com>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.
>> >