A method for providing SSO authentication when accessing non-SSO-compliant applications, the method including forwarding a user name and a password received from a non-SSO-compliant application to an SSO proxy, encapsulating the user name and password in a request to access a protected application, authenticating the user name and password responsive to the request using SSO authentication, and generating an SSO token if said authentication step is successful.

FIELD OF THE INVENTION

The present invention relates to client-server technology in general, and in particular to integrating non-SSO-compliant applications into an SSO system.

BACKGROUND OF THE INVENTION

Network-based applications often make use of many different technologies, object models, and programming languages, from simple Perl scripts and standalone applications implemented in C++ or Java™, to sophisticated applications running on J2EE application servers. In the past, access security was the responsibility of each application, requiring users to employ different user names and passwords for different applications. As users required access to increasing numbers of applications of all types, single sign-on (SSO) mechanisms were developed to standardize access security protocols and form application domains whereby users are given access to applications within the domain without having to separately sign on to each application. To accomplish this, all security algorithms are typically found in a single SSO server which acts as the only authentication point for a defined domain. Thus, a user signs on and is authenticated only once, and thereafter may securely interact with many different elements within a given domain. This is typically done by generating an SSO token for the user after the user is first authenticated, providing the token to the user, and thereafter having the user pass the token to other SSO applications which validate the token with the SSO server.

Unfortunately, not all applications are SSO-compliant. To remedy this, non-SSO-compliant applications may be modified internally to implement SSO mechanisms. However, such applications would need to be modified each time there is a change to the SSO protocol at the SSO server level. Enabling non-SSO-compliant applications to work within an SSO framework without requiring that the applications be modified internally to implement SSO mechanisms would therefore be advantageous.

SUMMARY OF THE INVENTION

The present invention discloses a system and method for integrating non-SSO-compliant applications into an SSO system.

In one aspect of the present invention a method is provided for providing SSO authentication when accessing non-SSO-compliant applications, the method including forwarding a user name and a password received from a non-SSO-compliant application to an SSO proxy, encapsulating the user name and password in a request to access a protected application, authenticating the user name and password responsive to the request using SSO authentication, and generating an SSO token if the authentication step is successful.

In another aspect of the present invention the method further includes providing the SSO token, the user name, and a notification of the successful authentication to a server.

In another aspect of the present invention the method further includes providing the SSO token and the user name to the protected application.

In another aspect of the present invention the method further includes providing the token and a notification of the successful authentication to the SSO proxy.

In another aspect of the present invention the method further includes configuring the SSO proxy as an HTTP client.

In another aspect of the present invention the method further includes configuring the encapsulated request as an HTTP request.

In another aspect of the present invention the method further includes sending the request to a J2EE server.

In another aspect of the present invention the method further includes configuring the protected application as a protected HTTP servlet residing on a J2EE server.

In another aspect of the present invention a system is provided for SSO authentication for use with non-SSO-compliant applications, the system including an SSO proxy operative to receive a user name and password from a non-SSO-compliant application and encapsulate the user name and password in a request to access a protected application, and an authenticator operative to authenticate the user name and password responsive to the request using SSO authentication and generate an SSO token if the authentication is successful.

In another aspect of the present invention the authenticator is operative to provide the SSO token, the user name, and a notification of the successful authentication to a server.

In another aspect of the present invention the server is operative to provide the SSO token and the user name to the protected application.

In another aspect of the present invention the protected application is operative to provide the token and a notification of the successful authentication to the SSO proxy.

In another aspect of the present invention the SSO proxy is an HTTP client.

In another aspect of the present invention the encapsulated request is an HTTP request.

In another aspect of the present invention the server is a J2EE server.

In another aspect of the present invention the protected application is a protected HTTP servlet residing on a J2EE server.

In another aspect of the present invention a method is provided for providing SSO authentication when accessing non-SSO-compliant applications, the method including forwarding a user name and token received from a non-SSO-compliant application to an SSO proxy, encapsulating the user name and token in a request to access a protected application, authenticating the token responsive to the request using SSO authentication, and generating a security context for the request if the authentication step is successful.

In another aspect of the present invention the generating step includes generating the security context to include the authenticated token and the user name.

In another aspect of the present invention the method further includes passing the request, the user name, and a notification of the successful authentication to a server.

In another aspect of the present invention the method further includes passing the request, the user name, and a notification of the successful authentication to the protected application.

In another aspect of the present invention the method further includes comparing the user name received with the request with the user name received with the security context of the request, and providing an affirmative response to the request if the user names match.

In another aspect of the present invention the providing step includes providing the affirmative response to the SSO proxy.

In another aspect of the present invention the method further includes configuring the SSO proxy as an HTTP client.

In another aspect of the present invention the method further includes configuring the encapsulated request as an HTTP request.

In another aspect of the present invention the method further includes sending the request to a J2EE server.

In another aspect of the present invention the method further includes configuring the protected application as a protected HTTP servlet residing on a J2EE server.

In another aspect of the present invention a system is provided for SSO authentication for use with non-SSO-compliant applications, the system including an SSO proxy operative to receive a user name and token from a non-SSO-compliant application and encapsulate the user name and token in a request to access a protected application, and an authenticator operative to authenticate the user name and token responsive to the request using SSO authentication and generate a security context for the request if the authentication step is successful.

In another aspect of the present invention the security context includes the authenticated token and the user name.

In another aspect of the present invention the authenticator is operative to pass the request, the user name, and a notification of the successful authentication to a server.

In another aspect of the present invention the server is operative to pass the request, the user name, and a notification of the successful authentication to the protected application.

In another aspect of the present invention the protected application is operative to compare the user name received with the request with the user name received with the security context of the request, and provide an affirmative response to the request if the user names match.

In another aspect of the present invention the protected application is operative to provide the affirmative response to the SSO proxy.

In another aspect of the present invention the SSO proxy is an HTTP client.

In another aspect of the present invention the encapsulated request is an HTTP request.

In another aspect of the present invention the server is a J2EE server.

In another aspect of the present invention the protected application is a protected HTTP servlet residing on a J2EE server.

In another aspect of the present invention a method is provided for implementing SSO authentication in support of non-SSO-compliant application access, the method including providing a SSO proxy operative to receive a user name and a password from a non-SSO-compliant application, and configuring the SSO proxy to a) encapsulate the user name and password in a request to access a protected application, and b) send the request to a computer operative to c) authenticate the user name and password responsive to the request using SSO authentication, and d) generate an SSO token if the authentication is successful.

In another aspect of the present invention a computer program is provided embodied on a computer-readable medium, the computer program including a first code segment operative to forward a user name and a password received from a non-SSO-compliant application to an SSO proxy, a second code segment operative to encapsulate the user name and password in a request to access a protected application, a third code segment operative to authenticate the user name and password responsive to the request using SSO authentication, and a fourth code segment operative to generate an SSO token if the authentication is successful.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Reference is now made toFIG. 1, which is a simplified block-flow diagram of an SSO system supporting authentication by password for non-SSO-compliant applications, constructed and operative in accordance with a preferred embodiment of the present invention, andFIG. 2, which is a simplified flowchart illustration of an exemplary method of operation of the system ofFIG. 1, operative in accordance with a preferred embodiment of the present invention. In the system ofFIG. 1and method ofFIG. 2, a non-SSO-compliant application100is accessed by a computer user102who provides a user name and password to application100. Application100then provides the user name and password to an SSO proxy104, preferably being an HTTP client. Proxy104sends the user name and password in a request, preferably encapsulated in an HTTP request, to a server108, preferably being a J2EE server, to access an application106, preferably being a protected HTTP servlet. Server108passes the request to an authenticator110, typically residing on server108, which authenticates the user name and password using any SSO authentication technique. If the user name and password fails the authentication process, authenticator110notifies server108of the failed authentication. Server108then notifies proxy104of the failed authentication, whereupon the proxy104may likewise notify non-SSO-compliant application100of the failed authentication, which in turn may likewise notify user102of the failed authentication. If the user name and password passes the authentication process, authenticator110generates an SSO token and passes it to server108along with the user name and a notification that the user passed. Server108then passes the user name and token to application106along with the authentication notification. Application106then passes the token and the authentication notification to proxy104, typically by first passing the token and the authentication notification to server108, which then passes the token and the authentication notification to proxy104. Proxy104may then pass the token on to the user.

Reference is now made toFIG. 3, which is a simplified block-flow diagram of an SSO system supporting authentication by token for non-SSO-compliant applications, constructed and operative in accordance with a preferred embodiment of the present invention, andFIG. 4, which is a simplified flowchart illustration of an exemplary method of operation of the system ofFIG. 3, operative in accordance with a preferred embodiment of the present invention. In the system ofFIG. 3and method ofFIG. 4, where authenticator110has already authenticated user102and generated an SSO token for user012, the next time user102wishes to access a non-SSO-compliant application, which may again be application100or a different application, the user provides his user name and token. Application100sends the user name and token to proxy104and requests authentication. Proxy104sends the user name and token in a request, preferably encapsulated in an HTTP request, to server108to access application106. Server108passes the request to authenticator110which authenticates the token using any SSO authentication technique. If the token fails the authentication process, authenticator110notifies server108of the failed authentication. Server108then notifies proxy104of the failed authentication, whereupon proxy104may likewise notify application100of the failed authentication, which in turn may likewise notify user102of the failed authentication. If the token passes the authentication process, authenticator110generates a security context for the request, which preferably includes the authenticated token and associated user name, and passes the request to server108along with the user name and a notification that the token passed authentication. Server108then passes the request to application106along with the user name and the authentication notification. Application106then requests the security context of the request from authenticator110. Application106then compares the user name received with the request with the user name received with the security context of the request. If the user names match, application106then passes to server108an affirmative response to the request, which server108then forwards to proxy104.

It is appreciated that one or more of the steps of any of the methods described herein may be omitted or carried out in a different order than that shown, without departing from the true spirit and scope of the invention.

While the methods and apparatus disclosed herein may or may not have been described with reference to specific computer hardware or software, it is appreciated that the methods and apparatus described herein may be readily implemented in computer hardware or software using conventional techniques. Thus, for example, client-side components described hereinabove may be implemented using the Extensible Markup Language (XML), Hypertext Markup Language (HTML), JavaScript™, Java Applets, ActiveX™, or any combination thereof.