Authentication and authorization for a distributed system

I work on the architecture of a distributed system, mainly in ruby โ€‹โ€‹(rails, sinatra, etc.).

I have some pure API components, for example API_C1, API_C2, API_C3. It has several web client applications, such as Portal1, Portal2, and some native client applications, such as Native1.

Requirements:

  • SSO for all web clients (Portal1, Portal2), centralized authentication.
  • All API components must provide their authorization API.
  • Centralized API authorization.

I did some POC to try some options, but still don't have a complete picture.

I tried the rubycas server for SSO. It works very well. I believe that if necessary, use the java cas implementation.

Centralized API authorization is pretty complicated for me. I am leaning towards the OAuth2 path, but I have a few questions:

  • Is it possible to have a centralized OAuth provider serving all of the API components? How should this work then and which libs / gems to use?
  • How can I make my web applications (Portal1 and Portal2) trusted by default. I do not want the user to allow access to trusted applications.
  • For my own client applications (not a web environment) I want to support 2 OAuth legs. Right choice? Is it possible to have both 3 legs and 2 legs?

  • How do custom creds convert to oauth token? Assume the following use case:

    • the user logs into Portal1 (via the CAS server) and opens the page
    • Portal1 server server must retrieve data from API_C1 and API_C2 to show the page. How to enable API here?

I have some thoughts similar to APIs in a single SSO CAS session. This kind of allows me to resolve my scenario 4), there is nothing to code here. But using a session for APIs is bad practice, and how then to mix session and OAuth authorization for the API?

Please point me in the right direction. Could there be some other options to do everything as configured OpenId or OAuth providers to support single sign-on?

+4
source share
1 answer

Although this is an old question (2 years ago), however, I will leave an answer here if someone tries to solve a similar problem.


I think you are taking the right direction when thinking about using OAUTH, however I would recommend that you use version 2.0 of the OAUTH protocol

Centralized authorization

Is it possible for a centralized OAuth provider to serve all API components? How should this work then and which libs / gems to use?

  • OAUTH 2.0 resolves this scenario when the Authorization Service works as a separate system / service, other services on your system can simply trust this service and know how to check its issued tokens (using x.509 public key of the certificate).

  • There are SaaS-based authorization servers that you can use even without any installation costs, for example Auth0

Web Clients

How can I make my web applications (Portal1 and Portal2) trusted by default. I do not want the user to allow access to trusted applications.

  • Using the resource ownerโ€™s password , the user (resource owner) is authenticated to the client (website / portal / application) using username and password along with the known client_id (which can also be tied to a known HTTP start)

  • As an alternative, provide an authorization code where the portal redirects the user to a known URL of the authorization service with some URL parameters for the user to authenticate there and redirects back to the portal

Native apps

For my own client applications (not a web environment) I want to support 2 OAuth legs. Right choice?

  • in OAuth 2.0, use client credentials in this scenario, where you can store client_id and client_secret and send them to the authorization server to authenticate as a trusted client (no user credentials are required).

Mixing everyone together

Is it possible to have both 3 legs and 2 legs?

  • All of the above types of grants for OAuth 2.0 can work together on the same service / authorization server (as far as I know. I really got it with Microsoft OWIN for ASP.net )

How do custom creds convert to oauth token? Assume the following use case:

  • The authorization service has endpoints (URLs) that clients use to submit a form or redirect to receive an access_token , but the actual method depends on which authentication flow you use (post vs redirect)

the user enters Portal1 (through the CAS server) and opens a page. The server back1 of the Portal1 server must retrieve data from API_C1 and API_C2 to show the page. How to enable API here?

  • using the resource ownerโ€™s password, the user enters username and password in portal1, then access_token , then when portal1 calls API_C1, it can simply attach access_token to the call (HTTP Header: Authorization ) (impersonating an incoming user)

  • using the authorization code, the user is redirected to Auth Service, enters their credentials there, and then redirected back to portal1 (client) using access_token , which then joins the API_C1 call to impersonate the registered user

Related topics

Finally, look at a similar answer related to your question

+1
source

All Articles