views:

477

answers:

4

[ # question edited for clarification # ]

I'm trying to implement a Single Sign On (SSO) for a web application. Maybe you can help me find a proper solution, give me a direction or tell me, that solutions already exist.

The scenario: A GeoExt (ExtJS for geodata/map based apps) webapp (JavaScript only) will be deployed on a customer's webserver.

The customer will define "usecases" or "profiles": A set of services like webservices, GeoServer WFS, WCS, Google Maps, etc. These services might require additional authentication like credentials or keys.

A user (who has to register and apply for a "profile") can (as soon a the application was granted) retrieve the credentials required to access the services associated to his profile. Like in a normal SSO-solution the user won't need to enter each credential/key for himself to use the services.

[ # no changes from here on... #]

The main problem: I'm unable to modify the 3rd party services (e.g. Google) to add a SSO mechanism.

I'd like to have a solution that allows the user to log in once to have access to all the services required. My first idea was a repository that stores all the required credentials or keys. The user logs in and can retrieve all required information to acces sthe other services. Does anybody know of existing implementations, papers, maybe implementations of such services?

Other requirements: The communication between the JS application and the repository must be secure. The credentials must be stored in a secure manner. But the JS app must be able to use them to access the services (no chance to store a decryption key in a JS-app securely, eh? *g).

[edit] Proxying is not an option, because of the terms of use of the services involved.

A: 

Google already has a couple of SSO mechanisms - it supports SAML acting as a Service Provider (SP) (in certain situations) and OpenID when acting as an Identity Provider (IDP). You don't mention which other third party services you need to integrate with, but if they are compatible with either of these you could:

  1. Set up a SAML IDP and use this to SSO to Google and your other apps
  2. Use Google as your OpenID IDP (as this site does), and use this to SSO into other apps
Andrew Strong
I'm aware of mechanisms like SAML, OpenID or other services like OpenSSO. As far as i can see they won't help me in my situation.The services i want to integrate are mostly commercial web feature services or web services that require authentication but are not compatible with any SSO toolbox. They usually only provide basic authentication over http(s). Some of these services were developed in-house and can be refitted, but not all of them.Like I said:In most cases there's no possibility to modify the services.
lajuette
+1  A: 

Does access to the webservices have to be within a user context or are they generic webservices?

If not, you could handle the authentication and communication with 3rd party webservices on your web server and route the messages from your server to your clients. This way you can simply use service accounts for 3rd party providers instead of having to track and store user accounts & passwords.

Leigh Shayler
The Services are generic webservices and are not under my control. Some services may prohibit proxying (or "routing") of the requests.
lajuette
A: 

I think you should wrap/proxy each web service that needs to be implemented. This might sound like a lot of work for each service, but you may be able to find common themes.

Details: Provide a WS from your web server that takes the user's profile identity and then actually calls the real web service with the correct credentials (retrived from server-side storage). Thus, no credentials need to be made available to the user in the client. The client javascript only needs to call your server. And you can implement your SSO API by wrapping the other services.

Caution: Double check the "fair use" license for each web service. Some of them will detect high number of calls from a single IP as a violation of their service agreement and then block or black-list your server.

Jennifer Zouak
As i said before: "Some services may prohibit proxying (or "routing") of the requests." I can't wrap the services, because each client will use different services and his own credentials. I could write an extensible interface that takes adapters for each service, but that's not an option, too. We are talking about customers who aren't IT-specialists.
lajuette
A: 

We've done something similar, using Drupal to act as the framework. http://www.drupal.org

You can use Drupal's built in authentication or use a SSO solution such as Shibboleth along with the module for it at http://drupal.org/project/shib_auth or OpenID which is available as a core module.

Once there, your world opens up to consuming services via many methods, drupal_http_request or http://drupal.org/project/rest_client a Rest client module, or WSRP http://drupal.org/project/wsrp or even shudder as some developers made us consume their service via an Iframe. The best part is there are a lot of modules already created to consume existing services, like Gmaps http://drupal.org/project/gmap and Amazon http://drupal.org/project/amazon etc.

Hope that is helfpul, and I'd be glad to elaborate further, as we consume services in many different ways. Cheers.

nowarninglabel
I can't wrap the services that will be used, i can't modify them, nor do i know which services the customer wants to use.
lajuette