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

Version 1 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 suggested using 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

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/