Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Background information required to understanding the thought process and planning behind integrating A&A to HySDS

OpenID Connect 1.0

OpenID Connect is:

… a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

It creates a set of standards which allows for SSO in a secure manner

  • OpenID Connect can ensure that a user can sign into one application and be authorized to use all apps that are protected as well

  • OpenID Connect provides multiple types of “flows” to authorize users:

    • Implicit flow - a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step

      • hysds_ui will use an implicit flow because it is a pure javascript (front-end) application

    • Authorization flow to redirect users to login to a identity provider (Google, Facebook, etc.)

      • returns an authorization code, which in turn will be used by the your app’s backend to fetch an id_token, access_token and refresh_token to the client

    • there are more but Authorization flow and Implicit flow are the most common

The access_token & refresh_token will be used to grant access to clients

  • The tokens are JWT tokens

    • JWT tokens allow systems to encode a JSON object into the token itself, which can be decoded by the application to retrieve user information (email, username, roles, etc.)

    • JWT tokens are separated into 3 sections:

      • Header - info on encode algorithm

      • Payload - user info (email, username, roles, etc.)

      • Signature - created by taking the encoded header, the encoded payload, a secret, the algorithm specified in the header, and signing it

        • it will ensure if the token has been tampered with (and ultimately reject the token)

JWT tokens are the best options for the “micro-service” architecture (multiple REST APIs) of HySDS because:

  • one set of tokens (access_token, refresh_token) can be re-used by multiple applications

  • tokens can be decoded and the payload can be read to ensure role-based access to REST API endpoints

  • According to OpenID Connect standards, user info can be retrieved in 2 ways:

    • online method, making a request to the provider’s UserInfo endpoint

      • curl https://[provider endpoint]/.../protocol/openid-connect/userinfo

      • reliable but can increase latency of having to make additional requests to retrieving user info every time your service is being called (not scalable in the long run)

    • decoding JWT token

      • the user info is encoded in the token and can be retrieved without having to make additional requests (more scalable)

      • requirements:

        • if using the HS256 algorithm, tokens can be encoded and decoded with the secret_key

          • not secure. if the secret_key gets leaked users can create their own JWT tokens and can potentially have “superuser” access to your system

        • if using the RS256 algorithm (more secure):

          • tokens will be encoded with a private_key

          • tokens will be decoded with a public_key

          • import json
from authlib.jose import jwt

public_key = """
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAi2W0DkV...
-----END PUBLIC KEY-----
"""

token = 'eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJ0czA0c...'

claims = jwt.decode(token, public_key)
claims.validate()  # will raise error if token expired

Example of JWT token:

There are multiple SSO providers that use OpenID Connect for A&A:

SSO Providers:

Keycloak

Originally the plan was to use Keycloak for A&A:

Pros:

  • Able to handle separate role level access with the use of JWT Tokens

  • Open-source (supported by RedHat)

  • LDAP integration

    • sync/import users from LDAP group to internal database

Cons:

  • Requires a SQL database (MySQL, PostgreSQL, etc.)

OCIO advised against using Keycloak, instead suggesting AWS Cognito

[meeting] with OCIO where 4 other projects are also working on Jupyter notebooks front-end to PCMs. The topic was raise for FN and public access to be able to sign into ADE+PCM for on-demand use. As a heads up, OCIO is recommending to not use Keycloak and instead use AWS Cognito with some additional ELB proxies

AWS Cognito

According to this StackOverflow post:

Cognito exposes an OpenID Connect Discovery endpoint as described at https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest at the following location:

https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/openid-configuration

Because Cognito can be exposed as an OpenID Connect provider, a lot of what we have researched on OpenID Connect (specifically Keycloak) can be applied in Cognito as well

  • but will still need to do additional research on implementation

Cognito doesn’t have clear instructions how to sync your LDAP directory so will need to do further research. Related links:

  • No labels
Note: JPL employees can also get answers to HySDS questions at Stack Overflow Enterprise:

https://stackoverflow.jpl.nasa.gov/