RE: [id-cloud] Doron Cohen (SafeNet) submission of use cases

["Cohen, Doron" <Doron.Cohen@safenet-inc.com>]

Anil, 

Next meeting should be fine.

Doron

-----Original Message-----
From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com] 
Sent: Thursday, June 17, 2010 21:02
To: id-cloud@lists.oasis-open.org
Subject: Re: [id-cloud] Doron Cohen (SafeNet) submission of use cases

Doron,
   thanks for the submission.  Can we schedule this for the next meeting 
(June 28th)?

I wanted to present my use cases but I will be traveling the week prior. 
Hence will not be in a position.

Regards,
Anil

On 06/17/2010 06:38 AM, Cohen, Doron wrote:
> Name of the member (s): Doron Cohen
>
> Affiliation: SafeNet Inc
>
> Version: 1.0
>
>
> ~~~~~~~
>
> Use Cases:
>
> ~~~~~~~
>
> 1.  Privileged Account Authentication
>
>
> With enterprises expanding their application deployment using private and public clouds, the privileged account control and authorization expands beyond the traditional IT administrator account security.
>
> Enterprises now have new cloud applications and cloud infrastructure administrative that are capable of reconfiguring and modifying existing services and instances as well as deploying additional services with potentially broad impact on application service levels, services costs, and even organizational compliance status. As such, security controls on the authentication, authorization, and auditing of cloud infrastructure administrative accounts is a critical aspect of supporting the shift to the cloud architectures.
>
>
>
> Requirements:
>
>
> 1.1. Authentication - be able to authenticate using high levels of assurance, authentication schemes, and multi factor authentication.
> 1.2. Authorization - fine grain administrative controls with approval workflow schemes
> 1.3. Privileged accounts auditing and attestation
> 1.4. Audit trails - be able to record administrative events in a tamper evident/tamper resistance transaction log
>
> 2. Enterprise User Authentication - extending enterprise identity using Federated SSO
>
>
> With enterprises expanding their application deployments using private and public clouds, the identity management and authentication of users to the services need to be decoupled from the cloud service in a similar fashion to the decoupling of identity from application in the enterprise. Users expect and need to have their enterprise identity extend to the cloud and used to obtain different services from different providers rather than multitude of userid and passwords.
>
> By accessing services via a federated enterprise identity, not only the user experience of SSO is to gain, but also Enterprise compliance and for control of user access, ensuring only valid identities may access cloud services.
>
>
>
> Requirements:
>
>
>
> 2.1. Authentication - be able to authenticate using different levels of assurance and authentication schemes (password, certificate, biometrics, hw tokens, out of band) .
>
> 2.2. Federated SSO
>
> 2.3. Federated Provisioning
>
> 2.4  Compatibility with different end points and form factors - PCs, tablets, thin clients and smart phones as used by employees and mobile workforce.
>
>
> 3. Cloud identity SSO - Authentication as a Service
>
>
> With the broadening of services offered in the cloud, the identity management and authentication of users to the services is under pressure to be decoupled from the cloud services themselves. From a user perspective, Users subscribing to an array of cloud services expect and need to have an interoperable identity that would be used to obtain different services from different providers.
>
>  From a cloud provider perspective, being able to interoperate with identities the user already have, helps to attract new customers, and would simplify the identity management overhead of the service provider.
>
>
>
> A cloud centric authentication service, using federated identity standards such as SAML and WS-Federation, is a key component of a streamlined user experience and obtaining trust in the cloud.
>
>
>
> Requirements:
>
>
>
> 3.1. Authentication - be able to authenticate using different levels of assurance and authentication schemes (password, certificate, hardware tokens, out-of-band).
>
> 3.2. Privacy - user should be able to authenticate once and control the level of disclosure when accessing different service providers and relaying parties
>
> 3.3  Compatibility with diverse end points and form factors - PCs, operating systems, web browsers and mobile devices
>
> 4.  Transaction Validation&  Signing in the Cloud
>
>
> As business applications and services are moving from the internal perimeter and to the cloud, there is a need in transaction integrity and validation for cloud transactions. Users and systems that consume cloud services present themselves in different form factors and end points, including, but not limited to traditional PCs and tablets as well as mobile devices and smart phones. As access to cloud hosted resources and applications increase, so does the need to provide a transaction validation and signing for business applications.
>
>
>
> Authentication of the user performing the transaction is the basis for transaction authorization in the cloud. Furthermore, there is a need for a robust validation of transaction integrity that does not only rely on the authenticity of the user session, but also on the entire transaction content.  Electronic and digital signing of the transaction that validates the identity of person or system, as well as the transaction details is required.
>
>
>
> Requirements:
>
>
>
> 4.1. Authentication - be able to authenticate users (a person), system (automated system) and organizations using different levels of assurance and authentication schemes (password, certificate, hw tokens, out of band, biometric).
>
> 4.2. Transaction Signing - be able to sign transaction details by binding identity, transaction information and a signature using compliant certification levels such as common criteria or FIPS certification
>
> 4.3  Transaction Auditing - be able to record signing events in a tamper evident/tamper resistance transaction log
>
>    

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.