Under your assumptions you state "for the purposes of this
TC, the customers of these cloud applications is the enterprise."
Did you mean for the purposes of this use case, or did you
actually intend to say that this TC should only deal with cloud applications
where the enterprise is the customer?
Michael Stiefel
From: Patrick Harding
[mailto:pharding@pingidentity.com]
Sent: Thursday, July 08, 2010 10:15 AM
To: id-cloud
Subject: [id-cloud] Use Cases
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.