Skip to content

Latest commit

 

History

History
258 lines (182 loc) · 9.47 KB

azure_ad.md

File metadata and controls

258 lines (182 loc) · 9.47 KB
Raw

Frinx Machine with Azure AD

Frinx Machine supports authentication and authorization via Azure AD. The following sections describe how to set up Azure AD for Frinx Machine.

Client configuration

Register the application in your Azure AD and configure the following settings.


Redirect URIs

Set platform redirect URIs on the Authentication page. The table below shows examples of configuration settings.

Syntax Platform configuration Redirect URI
Frontend Login Single-page application https://<IP/DNS>/ ,e.g. https://localhost/
Workflow-Manager docs (swager) Web https://<IP/DNS>/api/workflow/oauth2-redirect.html
Cloud swagger Web https://editor.swagger.io/oauth2-redirect.html
Local Postman Web https://oauth.pstmn.io/v1/callback
Cloud Postman Web https://getpostman.com/oauth2/callback

Frontend login URI is passed to the installation script azure_ad.sh via --redirect_url flag.


Implicit flow and single/multi tenancy settings

On the same page choose single/multi tenancy. Based on this setting, the parameter --tenant_name is defined in the installation script azure_ad.sh.

For a single-tenant, use Azure AD domain name from AD overview. For multi-tenant use value common.

Enabled implicit flow is optional based on specific requirements.

token config


API permissions

client api permissions


Client secrets

Generate secret and use it as an input parameter for --client_secret flag in the installation script azure_ad.sh.

This secret is used in KrakenD azure plugin for translating group id to the group name (human-readable format).

azure secrets

Token claims configuration

token config

Example of encoded JWT token with claims. These claims are transferred to the request header (see KrakenD Azure Plugin docs for more info).

{
  ......
  "tid": "aaaaaaaa-1234-5678-abcd-abcd12345678",
  "name": "Test User",
  "oid": "d040c2a8-aaaa-bbbb-cccc-f2900fea4f51",
  "preferred_username": "[email protected]",
  "roles": [
    "User.ReadWrite"
  ],
  "groups": [
    "bbbbbbbb-cccc-1234-5678-abcd12345678"
  ],
  ......
}

Docker secrets configuration

These settings should be generated by azure_ad.sh script.

frontend

Settings for Frontend authorization popup window

  • AUTH_CLIENT_ID : App (Client) ID
  • AUTH_REDIRECT_DOMAIN : IP/DNS of server without scheme (http(s)://) !!!
  • MSAL_AUTHORITY : url for logging to Azure AD with tenant name

inventory

Settings for devices owner installed in uniconfig-zones via inventory.

  • X_TENANT_ID : tenant id where '-' are replaced with '_'

workflow-proxy

Settings for uniconfig/workflow-manager swagger docs.

KrakenD AZURE AD PLUGIN SETTINGS

Settings for azure-ad plugin and jwt validation

  • AZURE_LOGIN_URL : url for logging to Azure AD, default: https://login.microsoftonline.com
  • AZURE_TENANT_NAME : tenant domain name
  • AZURE_TENANT_ID : tenant id where '-' are replaced with '_'
  • AZURE_KRAKEND_PLUGIN_CLIENT_ID : App (Client) ID
  • AZURE_KRAKEND_PLUGIN_CLIENT_SECRET : App (Client) secret
  • AZURE_KRAKEND_PLUGIN_JWT_VALUE_PREFIX=Bearer
  • AZURE_KRAKEND_PLUGIN_GROUP_DISABLE=false

AZURE_KRAKEND_PLUGIN_GROUP_DISABLE : set true, when only Role based access is used

RBAC configuration

All default settings are defined in config/secrets/frinx_rbac and are stored to docker secrets during execution of ./install.sh

Workflow-Manager RBAC

RBAC proxy adds 2 features on top of tenant proxy:

  • Ensures user authorization to access certain endpoints
  • Filters workflow definitions and workflow executions based on user's roles, groups and userID

RBAC support simply distinguishes 2 user types: an admin and everyone else. An admin has full access to workflow API while ordinary user can only:

  • Read workflow definitions
    • Ordinary user can only view workflow definitions belonging to the same groups
    • A workflow definition (created by an admin) can have multiple labels assigned
    • A user can belong to multiple groups
      • User groups are identified in HTTP request's header field x-auth-user-roles
    • If an ordinary user's group matches one of workflow labels, the workflow becomes visible to the user
  • Execute visible workflow definitions
  • Monitor running executions
    • Only those executed by the user currently logged in

Define user roles in workflow by adding role or group name to description label.

Example: added User.ReadWrite, Role.ReadWrite, Group.ReadWrite labels to workflow description.

{
  "name": "Install_all_from_inventory",
  "description": "{\"description\": \"Install all devices from device inventory\", \"labels\": [\"User.ReadWrite\", \"Role.ReadWrite\", \"Group.ReadWrite\"]}",
  "version": 1,
  "tasks": [
  ......

Admin role is configured via 'frinx_rbac' secret:

ADMIN_ACCESS_ROLE=All.ReadWrite

Inventory RBAC

RBAC support simply distinguishes 2 user types: an admin and everyone else.
An admin has full access to inventory API while ordinary user can only read from inventory

Configure admin role in 'frinx_rbac' secret file via:

INVENTORY_ADMIN_GROUP
user/request READ (query) WRITE (mutation)
Admin (Super user) TRUE TRUE
Regular user TRUE false

Resource-Manager RBAC

A simple RBAC model is implemented where only admin (based on their role and user groups) can manipulate resource types, resource pools and labels.
Regular users will only be able to read the above entities, allocate and free resources.

Configure admin role in 'frinx_rbac' secret file via:

# RESOURCE-MANAGER RBAC SETTINGS
# VALUES MUST BE IN QUOTATION MARKS
RM_ADMIN_GROUPS="network-admin"
RM_ADMIN_ROLES="network-admin"
user/request READ WRITE
Admin (Super user) TRUE TRUE
Regular user TRUE false

Uniconfig RBAC

Admin (based on their role and user groups) can use all REST APIs.
Regular users will only be able to use GET REST API requests.

Configure admin role in 'frinx_rbac' secret file via:

UNICONFIG_CONTROLLER_ADMIN_GROUP
user/request READ (GET REQUEST) WRITE (ALL REQUEST)
Admin (Super user) TRUE TRUE
Regular user TRUE false

Unistore RBAC

User types:

  • Super admin : full access to unistore
  • Bearer admin : all read, access to bearer node
  • Service admin : all read, access to service node
  • Network admin : all read, access to network node

Configure node names in 'frinx_rbac' secret file via:

# DEFAULT NODE NAMES
UNISTORE_BEARER_NODE=bearer
UNISTORE_SERVICE_NODE=service
UNISTORE_NETWORK_NODE=network

Assign admin roles to nodes in 'frinx_rbac' secret file via:

# CONFIGURE ROLES via VARIABLES, EXAMPLE:
UNISTORE_CONTROLLER_ADMIN_GROUP # super admin roles, grant all permissions
UNISTORE_OTHER_PERMITTED_ROLES  # all requests allowed except requests with`node=...` denied 
UNISTORE_NETWORK_ROLE           # all requests allowed but only requests with`node=${UNISTORE_NETWORK_NODE}` allowed 
UNISTORE_SERVICE_ROLE           # all requests allowed but only requests with`node=${UNISTORE_SERVICE_NODE}` allowed 
UNISTORE_BEARER_ROLE            # all requests allowed but only requests with`node=${UNISTORE_BEARER_NODE}` allowed

#example
UNISTORE_SERVICE_ROLE=Service1.ReadWrite,Service2.ReadWrite

Example of request to unistore with defined node=service. 

/api/unistore/data/network-topology:network-topology/topology=unistore/node=service/...

Only super-admin and users with roles UNISTORE_SERVICE_ROLE=Service1.ReadWrite,Service2.ReadWrite have access permissions.

Table of permissions:

node / user roles READ-ONLY (GET request) without NODE UNISTORE_NETWORK_NODE UNISTORE_SERVICE_NODE UNISTORE_BEARER_NODE
UNISTORE_CONTROLLER_ADMIN_GROUP TRUE TRUE TRUE TRUE TRUE
UNISTORE_OTHER_PERMITTED_ROLES TRUE TRUE false false false
UNISTORE_NETWORK_ROLE TRUE TRUE TRUE false false
UNISTORE_SERVICE_ROLE TRUE TRUE false TRUE false
UNISTORE_BEARER_ROLE TRUE TRUE false false TRUE