Cisco Cisco Web Security Appliance S170 사용자 가이드

SAML is an XML-based standard for exchanging authentication and authorization data between 
different secure networks, sometimes referred to as security domains. The main problem that SAML 
solves is single sign-on between different security domains. Typically, SAML is used when there are 
users in one domain accessing a network (a different domain) using a web browser. This is sometimes 
referred to as web browser single sign-on.

To achieve web browser single sign-on, a SAML dialogue must be engaged by an entity in each domain, 
which SAML defines using the following terms:

Identity provider. An identity provider is an entity that produces SAML assertions. The identity 
provider is expected to authenticate its end users before producing a SAML assertion. The Web 
Security appliance is an identity provider.

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.

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.

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>.

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>.

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. 

The type of flow supported by a SaaS application determines how end users access the application. For 
more information, see 

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 at 

http://docs.oasis-open.org/security/saml/v2.0/

.

When users access a SaaS application, you can choose how to sign them into the SaaS application:

Always prompt users for their local authentication credentials. 

Prompt users for their local authentication credentials if the Web Proxy obtained their user names 
using transparent user identification. 

Automatically sign in users to the SaaS application using their local authentication credentials.