RE: [id-cloud] Gap Analysis Use Case 21: Mobile Customers' Identity Authentication Using a Cloud Provider (SAML)

["Nguyen, Dominique V" <dominique.v.nguyen@bankofamerica.com>]

 

This discussion thread is to start an on-list discussion on the Gap

 Analysis of individual use cases. Use case numbers refer to the use

 cases as described in the 'OASIS Identity in the Cloud TC Use Cases'

 Version 1.0, Working Draft 02, 15 December 2011, which is available at

 http://www.oasis-open.org/committees/document.php?document_id=44915&wg_abbrev=id-cloud

 

 

The information below describes the current state. You are invited to

 respond on-list to this thread with any comments, insights, additions, etc.

All input will be gathered from the list and consolidated into the

 next revision of the Gap Analysis document.

---

 

Use Case 21: Mobile Customers' Identity Authentication Using a Cloud Provider

 

Short description:

Feature the need to have a standard secure authentication in order to use Cloud service

to authenticate mobile users

 

Relevant applicable standards:

- SAML

- OAuth

- XSPA

- WS-Trust

- PMRM

 

 

SAML v2.0 Information Card Token Profile Vers1on 1.0 - Gap summary:

 

Security measures against Man-in-the-Middle, token confidentiality and integrity are too relaxed. 

See detailed notes included in Tables

 

Terms used in SAML and notes:

 

I.              SAML V2.0 Technical Overview doc.

 

SAML Participants

SAML exchanges take place between system entities referred to as a SAML asserting party and a SAML relying party. In many SAML

use cases, a user, perhaps running a web browser or executing a SAML-enabled application, is also a participant, and may even be the asserting party.

An asserting party is a system entity that makes SAML assertions. It is also sometimes called a SAML authority.

A relying party is a system entity that uses assertions it has received. When a SAML asserting or relying party makes a direct request to another SAML entity,

the party making the request is called a SAML requester, and the other party is referred to as a SAML responder. A replying party's willingness to

rely on information from an asserting party depends on the existence of a trust relationship with the asserting party.

 

SAML system entities can operate in a variety of SAML roles which define the SAML services and protocol messages they will use and  the types of assertions

they will generate or consume. For example, to support Multi-Domain Single Sign-On (MDSSO, or often just SSO), SAML defines the roles called identity

provider (IdP) and service provider (SP). Another example is the attribute authority role where a SAML entity produces assertions in response to identity

attribute queries from an  entity acting as an attribute requester.

 

At the heart of most SAML assertions is a subject (a principal – an entity that can be authenticated – within the context of a particular security domain)

about which something is being asserted. The subject could be a human but could also be some other kind of entity, such as a company or a computer.

The terms subject and principal tend to be used interchangeably in this document.

 

A typical assertion from an identity provider might convey information such as “This user is John Doe, he has an email address of john.doe@example.com,

and he was authenticated into this system using a password mechanism.” A service provider could choose to use this information, depending on its access

policies, to grant John Doe web SSO access to local resources.

 

II.            SAML  V2.0 Information Card Token Profile doc.

 

SAML is defined in terms of assertions, protocols, bindings, and profiles.

 

Assertions

An assertion is a package of information that supplies one or more statements made by a SAML authority. SAML defines three different kinds of

assertion statement that can be created by a SAML authority.

• Authentication: The specified subject was authenticated by a particular means at a particular time. This kind of statement is typically generated by a SAML authority called an identity provider, which is in charge of authenticating users and keeping track of other information about them.

• Attribute: The specified subject is associated with the supplied attributes.

• Authorization Decision: A request to allow the specified subject to access the specified resource has been granted or denied.

The outer structure of an assertion is generic, providing information that is common to all of the  statements within it. Within an assertion, a series of

inner elements describe the authentication, attribute, authorization decision, or user-defined statements containing the specifics.

 

Protocols

SAML defines a number of request/response protocols that allow service providers to:

• Request from a SAML authority one or more assertions (includes a direct request of the desired assertions, as well as querying for assertions that meet particular criteria)

• Request that an identity provider authenticate a principal and return the corresponding assertion

• Request that a name identifier be registered

• Request that the use of an identifier be terminated

• Retrieve a protocol message that has been requested by means of an artifact

• Request a near-simultaneous logout of a collection of related sessions (“single logout”)

• Request a name identifier mapping

 

Bindings

Mappings from SAML request-response message exchanges into standard messaging or communication protocols are called SAML protocol bindings.

For instance, the SAML SOAP Binding defines how SAML protocol messages can be communicated within SOAP messages, whilst the

HTTP Redirect binding defines how to pass protocol messages through HTTP redirection.

 

Profiles

Generally, a profile of SAML defines constraints and/or extensions in support of the usage of SAML or a particular application, the goal being to

enhance interoperability by removing some of the flexibility inevitable in a general-use standard. For instance, the Web Browser SSO Profile specifies

how SAML authentication assertions are communicated between an identity provider and service provider to enable single sign-on for a

browser user.

 

Standard/Protocol	Protect against Man-in-the-Middle Attack	When Message Integrity and Confidentiality required	When relying party requests assertion from an asserting party	When response message contains an assertion delivered to a relying party via a user’s web browser
SAML V2.0 (Technical Overview doc.)	Public Key Infrastructure (PKI) is recommended	HTTP over SSL/TLS is recommended	Bi-lateral authentication is required and the use of SSL/TLS using mutual authentication or authentication via digital signatures is recommended	Digitally signed response using XML Signature is required

 

Standard / Protocol

Unconstraint Bearer Assertions

SAML  V2.0  (Information Card Token Profile doc)

The Information Card model’s support for hiding the identity the Relying Party from the Identity Provider, combined with constraints on the implementation of the model for use with web browsers, leads to requests for “unconstrained” bearer assertions with no audience of subject confirmation conditions on use. While all uses of bearer assertions are subject to certain threats and attacks, the lack of conditions on such assertions introduces additional serious threats to consider. Ordinarily, the threat of stolen assertion is mitigated by the fact that it can only be used to authenticate to a particular Relying Party.  Without conditions on use, an attacker that successfully steals such an assertion has many more target of opportunity.  The ability to mount an attack against a user’s interactions with any single Relying Party becomes effective against all parties that are willing to accept such an assertion.  Consider that some low value services may choose to forgo the use of SSL/TLS, leaving the assertions issued for their use much more vulnerable to theft.  Relying Parties that choose to accept such assertions are in turn empowered with the opportunity to impersonate the user for the duration of the subject confirmation window with any other like-minded Relying Parties. One of the only mitigating mechanisms to these threats are to enforce restrictions on use of assertions based on an IP address placed into the assertion by the Identity Provider.  While moderately effective, this practice often proves impractical for services offered to large user population. This profile recommends against the use of unconstrained bearer assertions.

 

Regards,

Dominique

---------------------------------------------------------------------

To unsubscribe, e-mail: id-cloud-unsubscribe@lists.oasis-open.org

For additional commands, e-mail: id-cloud-help@lists.oasis-open.org

 

---

This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses.

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link:
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.