Cisco Cisco Web Security Appliance S380 Guía Del Usuario
14-3
Cisco IronPort AsyncOS 7.1 for Web User Guide
OL-23207-01
Chapter 14 Controlling Access to SaaS Applications
Understanding How SaaS Access Control Works
•
Service provider. A service provider is an entity that consumes SAML
assertions. The SaaS applications you configure on the Web Security
appliance are service providers. The service provider relies on the identity
provider to identify the end user and communicate that identification to the
service provider in the SAML assertion. The service provider makes an
access control decision based on the assertion.
assertions. The SaaS applications you configure on the Web Security
appliance are service providers. The service provider relies on the identity
provider to identify the end user and communicate that identification to the
service provider in the SAML assertion. The service provider makes an
access control decision based on the assertion.
SAML assertions are containers of information passed between identity providers
and service providers inside SAML requests and responses. Assertions contain
statements (such as authentication and authorization statements) that service
providers use to make access control decisions. Assertions start with the
<saml:Assertion> tag.
and service providers inside SAML requests and responses. Assertions contain
statements (such as authentication and authorization statements) that service
providers use to make access control decisions. Assertions start with the
<saml:Assertion> tag.
SAML dialogues are called flows, and flows can be initiated by either provider:
•
Service provider initiated flow. The service provider is contacted by an end
user requesting access so it starts a SAML dialogue by contacting the identity
provider to provide identification for the user. For service provider initiated
flows, the end user accesses the service provider using a URL that contains
the service provider’s domain, such as
http://www.serviceprovider.com/<URI>.
user requesting access so it starts a SAML dialogue by contacting the identity
provider to provide identification for the user. For service provider initiated
flows, the end user accesses the service provider using a URL that contains
the service provider’s domain, such as
http://www.serviceprovider.com/<URI>.
•
Identity provider initiated flow. The identity provider starts a SAML
dialogue by contacting the service provider requesting access on behalf of an
end user. For identity provider initiated flows, the end user accesses the
service provider using a URL that contains a local domain, such as
http://saas.example.com/<URI>.
dialogue by contacting the service provider requesting access on behalf of an
end user. For identity provider initiated flows, the end user accesses the
service provider using a URL that contains a local domain, such as
http://saas.example.com/<URI>.
SaaS applications define whether they support service provider or identity
provider initiated flows. For example, Salesforce supports identity provider
initiated flows, Google Apps supports service provider initiated flows, and Cisco
WebEx supports both.
provider initiated flows. For example, Salesforce supports identity provider
initiated flows, Google Apps supports service provider initiated flows, and Cisco
WebEx supports both.
The type of flow supported by a SaaS application determines how end users access
the application. For more information, see
the application. For more information, see
.
Note
This section does not provide a comprehensive discussion of SAML, nor how
identity and security providers communicate with each other. For more detailed
information, read about SAML on the web at
identity and security providers communicate with each other. For more detailed
information, read about SAML on the web at
http://docs.oasis-open.org/security/saml/v2.0/
.