CloudAccess supports single-sign for a variety of web services and applications that have different authentication requirements. The method used for single sign-on depends on the security requirements and capabilities of each destination resource.
Federated single sign-on relies on a trust relationship between an identity provider and a service provider to give a user access to a protected web service or application through CloudAccess. Open standards for federation include SAML 2.0 (Security Assertion Markup Language), WS-Federation (Web Services Federation), and SAML 2.0 Inbound. They provide a vendor-neutral means of exchanging user identity, authentication, and attribute information. The service provider trusts the identity provider to validate the user’s authentication credentials and to send identity information about the authenticated user. The service provider accepts the data and uses it to give the user access to the destination service or application. This data exchange is transparent for the user. It allows the user to access the web service or application without providing an additional password.
The following describes the SSO experience for trusted access to an application through CloudAccess:
The user provides login credentials directly to CloudAccess, such as their corporate user name and password.
CloudAccess authenticates the user’s credentials against the identity sources.
CloudAccess presents the landing page to the user with links to applications that the user is entitled to use.
When a user clicks an application’s link, as the identity provider, CloudAccess produces an authentication assertion or token for the service provider that contains the identity attributes needed for the user request.
The service provider consumes the assertion or token to establish a security context for the user.
The service provider validates the assertion and authorizes the resource request.
The service provider establishes a session with the user.
CloudAccess can also provide authentication when the user initiates access to the application from the service provider.
The following describes the SSO experience for trusted access to an application initiated from the service provider:
The user attempts to log in to an application.
The login is redirected to CloudAccess.
CloudAccess prompts the user for the user name and password. Or, if Kerberos is configured, CloudAccess performs seamless authentication.
CloudAccess verifies the user name and password using the identity sources. Or, if Kerberos is configured, CloudAccess validates the Kerberos token.
CloudAccess provides an assertion to the application service provider.
The service provider validates the assertion and allows the user to access the application.
Basic single sign-on provides an internal credentials store where users can save their credentials for third-party websites that require a password be sent at login. The destination website’s login page must use HTML Forms as the main point of interaction with the user. A user typically has a site-specific user name and password for each destination website. CloudAccess stores the user’s credentials for each site in AES-256 encrypted format. After a user authenticates to CloudAccess, the user can access a website without manually re-entering the user’s credentials for the site.
OAuth 2.0 single sign-on provides simple authenticated access to a protected web service through CloudAccess. CloudAccess behaves as an OAuth 2.0 Authorization Server and Resource Server to provide user authentication and all OAuth2 token creation and validation for access. It uses the Authorization Code flow as detailed in the OAuth 2.0 Authorization Framework (IETF RFC 6749) document.
CloudAccess supports OAuth 2.0 access in service-provider mode. End users can access the protected resource by browsing to the URL of the OAuth client application. For example, the user can enter the URL directly into the browser and be redirected to log in to CloudAccess, or they can use a bookmark or the landing page appmark after logging in to CloudAccess.
The following describes the experience for OAuth 2.0 access to an application by browsing to the URL:
The user accesses the protected resource by entering the URL directly in the browser.
The user is redirected to the CloudAccess login page.
The user provides login credentials to CloudAccess, such as their corporate user name and password.
CloudAccess authenticates the user’s credentials against the identity sources.
CloudAccess validates the OAuth2 token for the client.
The user gains access to the resource.
The following describes the experience for OAuth 2.0 access to an application through CloudAccess:
The user provides login credentials directly to CloudAccess, such as their corporate user name and password.
CloudAccess authenticates the user’s credentials against the identity sources.
CloudAccess presents the landing page to the user with links to applications that the user is entitled to use.
The user clicks the bookmark or the landing page appmark for the application.
CloudAccess validates the OAuth2 token for the client.
The user gains access to the resource.
Simple proxy single sign-on provides reverse proxy access to your enterprise web service through CloudAccess. If the web service requires user identity information to control access or content, you can configure the connector to inject the authenticated user’s identity attributes in query strings and HTTP headers sent to the web service. However, the connector cannot be used to provide single sign-on for web services that require passwords for access. This proxy solution cannot inject the password. It does not support site redirects.
The following describes the experience for simple proxy access to a web service through CloudAccess:
The user provides login credentials directly to CloudAccess, such as their corporate user name and password.
CloudAccess authenticates the user’s credentials against the identity sources.
CloudAccess presents the landing page to the user with links to applications that the user is entitled to use.
The user clicks the appmark for the application.
(Conditional) CloudAccess sends identity information about the user in query strings and headers.
The website validates the resource request.
The user gains access to the resource.
In CloudAccess, you can create bookmarks to access web applications through CloudAccess that do not require additional passwords. The bookmarks are accessible from the browser landing page or directly from the MobileAccess app on users’ mobile devices.
The following describes the experience for bookmark access to a web application through CloudAccess:
The user provides login credentials directly to CloudAccess, such as their corporate user name and password.
CloudAccess authenticates the user’s credentials against the identity sources.
CloudAccess presents the landing page to the user with links to applications that the user is entitled to use.
The user clicks the appmark for the bookmark.
The user gains access to the resource.