OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

id-cloud message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Use Case Submission


All,
Trying again. Comments welcome.

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

- for browser applications

- for APIís

2. Account Management

-†††††† consistent maintenance of user accounts within each cloud application

-†††††† ability to create, update and disable/delete these accounts in an automated way

3. Audit
††††††††††† - cloud application Access & Audit logs accessible to the enterprise in a consistent and secure manner


4. Authorization & Delegation

††††††††††† - a slippery slope :-)


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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]