Browse Prior Art Database

A method of providing SSO service between on-premise application and public cloud service

IP.com Disclosure Number: IPCOM000220208D
Publication Date: 2012-Jul-25
Document File: 7 page(s) / 149K

Publishing Venue

The IP.com Prior Art Database

Abstract

In Cloud, more and more customers face the issue of on-premise applications integrating with applications hosted in cloud and require Single Sign On (SSO) toolings. This article is to achieve SSO service using the underlying Application Server without any Proxy service as an independent platform service under SaaS (Software-as-Service)/cloud context. This SSO service help customers to establish SSO from legacy/on-premise system to SaaS tenant without needing complex toolings. It also brings a new SSO delivery model, which provides on-demand & lightweight approach

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 7

A method of providing SSO service between on-premise application and public cloud service

This solution is to enable SSO service as an independent platform service under SaaS (Software-as-Service)/cloud context. Such SSO service help customers to establish SSO from legacy/on-premise system to SaaS service.

SaaS is rarely a stand-alone application, even in cloud age customers still want to keep critical/confidential application/data locally though they could buy SaaS service running on public cloud. Such situation generally requires SSO between application on premise and SaaS on cloud to gain seamless integration and better usability. The complexity of such SSO is that different tenant has different security policy or SSO mechanisms.

The following diagram depicts an existing SSO solution, in this solution, SaaS service url is put into customer's existing application, after user clicks such link, it will bring customer to SaaS service UI without any further credential challenge, from Software-as-Service Provider side, an interceptor can intercept user request, and perform userid verification, if user id exists within corresponding user repository, SaaS service will consider such request is authenticated. This solution is good for stand-alone application, but it's not a good approach for multi-tenant scenario, there are some constrains to adopt such solution within SaaS context:


1) As shown in the diagram, for every on-premise application, corresponding tenant SSO logic should be developed and deployed on SaaS side


2) For every new customer onboarding, SaaS application owner needs to get involved with the new SSO solution development thereby increasing the delivery time for transition and transformation


3) This SSO is a factor for every Customer's in-house application that integrates with application on the Cloud


4) For clustering environment, such customized SSO has to be deployed into each application server node. And any update to SSO leads to redeployment

1


Page 02 of 7

Our solution is to pull the interceptor logic out of specific application server, and make it as a service outside of application server.

We place a standardized "SSO Service Client" module on application server side, which will intercept user's request and have a remote SSO service call to "SSO Service" module, the SSO result will be set by "SSO Service Client" to indicate if current request is "authenticated=true" or "authenticated=false".

Such SSO solution could better fit into multi-tenant service, e.g. SaaS.


1) It helps standardize SSO process in multi-tenant context, e.g. standardized SSO service client can be shipped along with Application Server Prod...