[ # 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 cr开发者_如何转开发edentials 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.
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.
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:
- Set up a SAML IDP and use this to SSO to Google and your other apps
- Use Google as your OpenID IDP (as this site does), and use this to SSO into other apps
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.
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.
精彩评论