Single sign-on for WebServices, WCS, WFS, WMS (Geoserver), etc.

[# question edited to clarify #]

I am trying to implement Single Sign On (SSO) for a web application. Maybe you can help me find the right solution, give me direction or say that solutions already exist.

Scenario: GeoExt (ExtJS for geodata / map-based applications) webapp (JavaScript only) will be deployed to the client web server.

The client will define "usecases" or "profiles": a set of services such as webservices, GeoServer WFS, WCS, Google Maps, etc. These services may require additional authentication, such as credentials or keys.

The user (who needs to register and apply for a "profile") can (as soon as the application is provided) receive the credentials necessary to access the services associated with his profile. As in the usual SSO solution, the user does not need to enter each account key / key for himself in order to use the services.

[# no changes here ... #]

The main problem: I can not change third-party services (for example, Google) to add the SSO mechanism.

I would like to have a solution that allows the user to log in once to gain access to all the required services. My first idea was a repository that stores all the necessary credentials or keys. The user is registered and can get all the necessary information to access other services. Does anyone know about existing implementations, documents, perhaps implementations of such services?

Other requirements. The connection between the JS application and the repository should be secure. Credentials must be stored in a secure manner. But the JS application should be able to use them to access services (there is no way to safely store the decryption key in the JS application, eh? * G).

[edit] Proxying is not an option due to the terms of use of the services involved.

+4
source share
4 answers

Should access to web services be in a user context or are they universal web services?

If not, you can process authentication and communication with third-party web services on your web server and forward messages from your server to your clients. That way, you can simply use third-party service accounts instead of tracking and storing user accounts and passwords.

+1
source

Google already has several single sign-on mechanisms - it supports SAML, acting as a service provider (SP) (in certain situations) and OpenID, acting as an identity provider (IDP). You do not specify which other third-party services you need to integrate, but if they are compatible with any of them, you can:

  • Configure SAML IDP and use it for SSO for Google and other applications.
  • Use Google as your OpenID IDID (like this site), and use it for SSO in other applications
0
source

I think you should wrap / proxy every web service that needs to be implemented. This may seem like a lot of work for each service, but you can find common topics.

Details: Provide WS from your web server, which accepts the user profile identifier, and then actually calls the real web service with the correct credentials (retrieved from the server storage). Therefore, credentials should not be provided to the user in the client. Javascript client only needs to call your server. And you can implement your SSO API by wrapping other services.

Caution: Double-check the fair use license for each web service. Some of them detect a large number of calls from the same IP address as a violation of their service agreement, and then block or blacklist your server.

0
source

We did something similar using Drupal to work as a framework. http://www.drupal.org

You can use Drupal, which is built into authentication, or use an SSO solution such as Shibboleth, together with a module for it http://drupal.org/project/shib_auth or OpenID which is available as the main module.

Once upon a time, your world will open to use services using many methods: drupal_http_request or http://drupal.org/project/rest_client client module Rest or WSRP http://drupal.org/project/wsrp or even shudder, as some developers forced us to use their service through an iframe. The best part is the many modules that are already created to use existing services, such as Gmaps http://drupal.org/project/gmap and Amazon http://drupal.org/project/amazon , etc.

I hope this is helfpul, and I would be happy to continue development, as we consume services in different ways. Greetings.

0
source

Source: https://habr.com/ru/post/1303769/


All Articles