Single Sign-on (SSO) allows users to sign on to all their applications and services with one set of credentials. It gives employees and customers secure, one-click access from anywhere, on any device, and it reduces the number of separate accounts and passwords they need to manage.
The proliferation of on-premises, cloud and SaaS applications requires more robust single sign-on solutions—but makes SSO exponentially more valuable. Many enterprises today employ federated SSO to enable authentication with a single set of credentials across multiple organizations and security domains. This means they can provide secure single sign-on to a trusted group of applications or “service providers,” even when the apps are owned by third parties or sit outside their firewalls.
How Single Sign-on Works
SSO is made possible by a centralized authentication service that all apps (even third-party) can use to confirm a user’s identity. Identity standards like SAML, OAuth and OpenID Connect allow for encrypted tokens to be transmitted securely between the server and the apps to indicate that a user has already been authenticated and has permission to access the additional apps.
Organizations want user identification and single sign-on performed in a secure, controlled and centralized manner across their diverse set of devices, networks, domains and platforms. This improves security and user convenience while lowering costs. An authentication authority serves as the single mechanism through which user identities are confirmed within an organization.
Service Provider Initiated SSO
In order to provide our customer's with single sign-on capability, Syniverse provides a solution based on identity federation. This provides a bridge to connect all the customer's user identities in one place and manage their access to Syniverse applications. This approach reduces the administrative overhead of managing the user identities within their own identity provider (IdP) and managing it separately within the Syniverse's identity provider. The federation solution is designed to work with any identity provider (IdP) and easily accepts SAML for SSO into Syniverse's applications.
In order to facilitate our customer's employees from accessing an application such as Syniverse Developer Community, users can leverage their SSO credentials to have the Syniverse application begin the SSO process and minimize password sprawl.
Security Assertion Markup Language (SAML)
Benefits of SAML Authentication
SAML is XML based, which makes it extremely flexible. Two federation partners can choose to share whatever identity attributes they want in a SAML assertion (aka message) payload as long as those attributes can be represented in XML. Interoperability also gives SAML a huge advantage over proprietary SSO mechanisms. With SAML, a single implementation can support SSO connections with many different federation partners.
How SAML Authentication Works
Enterprise SAML identity federation use cases generally revolve around sharing identity between an existing identity and access management (IAM) system and web applications. There are two actors in the SAML scenario, the Identity Provider (IdP) who “asserts” the identity of the user and the Service Provider (SP) who consumes the “assertion” and passes the identity information to the application. The interaction between the IAM system and the federation server is called “first mile” integration, while the interaction between the federation server and the application is called “last mile” integration.
SP-initiated SSO with SAML Authentication
SP-initiated SSO starts when a user tries to access a resource at the service provider, but hasn’t yet authenticated to the SP. A user may have gone directly to the website or may have saved a link to a specific resource at the SP. Once the SP sees that the user doesn’t have an active session, it will redirect them to the IdP to be authenticated. The IdP will authenticate the user, create the assertion and redirect the user back to the SP just as in the IdP-initiated use case, with the addition that it will also send back the URL of the resource that the user was initially trying to access, if it was provided by the SP.
Syniverse uses the approach to configure a 'resource URL' specific to a given IdP to determine which IdP should receive the request to authenticate the user, as Syniverse will be integrating with multiple IdPs for different customers requesting SSO integration using SAML.
Once the SP has received the SAML assertion, it validates the signature using the public key in order to ensure the SAML assertion really came from its trusted IdP and that none of the values in the assertion have been modified. The SP can then extract the identity of the user from the SAML assertion along with any other attributes it needs. At this point, the user is on the service provider’s landing page, just as though they had logged into the site manually.
User Access Provisioning
In order for the SSO to work, the customer's workforce users requiring access to Syniverse Developer Community would need to be pre-provisioned with the appropriate role on the Syniverse platform. Currently Syniverse does not support 'just-in-time' user provisioning of users that log on through SAML, they would always need to be pre-provisioned.
Users can be self provisioned as part of SDC company creation or using the company join capability with a predefined company join invite code. Roles can be administered by the Admin users provisioned with the User Administrator role via the portal. User provisioning can also be requested by submitting a request through the Syniverse support team with appropriate authorization forms required for audit purposes as the users are being provisioned on behalf of the customer. Syniverse currently does not support user provisioning or access management via SAML.
Additional information about how to perform user access management for Syniverse Developer Community and Voice and Messaging Console can be found in the following articles :
How to perform Syniverse Developer Community (SDC) User and Access Management
How to perform Voice and Messaging Console User Access Management
SSO Implementation
SSO integration request would need to be submitted to the Syniverse account team and would be treated as an implementation project closely coordinated between the customer's IdP management team and Syniverse portal team. Syniverse can also facilitate an end-to-end test of the SSO integration if the customer desires it in one of their non-production (development or test environments) as long as Syniverse is provided access to that environment.
0 Comments