Okta Authorization Server

Mag-set up ng custom na Okta authorization server na may mga claim, role, at access policy na kinakailangan ng Halo. Isa itong prerequisite para sa parehong Halo Portal SSO at Halo API Bearer Authentication.

Mga Kinakailangan

Isang Okta organization na may admin access
Network access mula sa iyong Halo deployment papuntang Okta

Gumawa ng authorization server

Navigate to Security -> API and create a new Authorization server.
- Magbigay ng angkop na pangalan. hal. Glasswall Halo
- Maglagay ng karaniwang audience value na ibabahagi sa lahat ng Halo client (Portal at API). hal. api://halo
- Magbigay ng angkop na paglalarawan. hal. Glasswall Halo Authorization server
- Kapag na-save na, itala ang Issuer Metadata URI. Alisin ang /.well-known/oauth-authorization-server sa dulo ng URI. hal.
```
export ORIGINAL_ISSUER_URI=https://your-org.okta.com/oauth2/aus1234567890abcdef/.well-known/oauth-authorization-server
export OKTA_ISSUER_URI=https://your-org.okta.com/oauth2/aus1234567890abcdef
export VALID_AUDIENCE="api://halo"
```

Screenshot: Create new authorization server Screenshot: Authorization server details with issuer URI

Tandaan: Ang audience na api://halo ay ibinabahagi sa lahat ng Halo client. Parehong bina-validate ng Portal SSO at API Bearer authentication ang mga token laban sa audience na ito. Dahil dito, maaaring magsilbi ang iisang authorization server sa parehong use case.

Magdagdag ng custom scope para sa access sa Halo API

Navigate to the Scopes tab on the authorization server and add a new scope:
- Pangalan: halo.api
- Display Phrase: Halo API
- Paglalarawan: Access to Halo API
- Lagyan ng check ang Set as a default scope

Screenshot: Custom scope configuration

Tandaan: Ang mga OIDC scope (hal. openid, profile, email) ay para lamang sa user-context at hindi maaaring gamitin sa Client Credentials flow. Kinakailangan ang custom scope para sa machine-to-machine API access.

I-set up ang claims

I-configure ang mga claim na kailangan ng mga serbisyo ng Halo. Pumunta sa tab na Claims sa authorization server.
- Full name:
  - Pangalan: name
  - Isama sa uri ng token: Access Token
  - Uri ng value: Expression
  - Value: user.firstName + " " + user.lastName
  - Isama sa: Any scope
- Family name:
  - Pangalan: family_name
  - Isama sa uri ng token: Access Token
  - Uri ng value: Expression
  - Halaga: user.lastName
  - Isama sa: Any scope
- Given name:
  - Pangalan: given_name
  - Isama sa uri ng token: Access Token
  - Uri ng value: Expression
  - Halaga: user.firstName
  - Isama sa: Any scope
- Email ID:
  - Pangalan: unique_name
  - Isama sa uri ng token: Access Token
  - Uri ng value: Expression
  - Halaga: user.email
  - Isama sa: Any scope

Screenshot: Claims configuration

Tukuyin ang mga role

Tandaan: Gumagamit ang Halo ng dalawang magkahiwalay na role claim:

roles: ginagamit ng Portal (sa pamamagitan ng Portal-Access) upang kontrolin ang access sa UI

role: ginagamit ng serbisyong API-Access para sa authorization ng endpoint

Kung hindi naka-configure ang mga role claim, ang Portal ay magde-default sa read-only na role at ang API ay magde-default sa role na User. Tingnan ang Portal Roles to Action Mapping at API Roles to Action Mapping para sa mga detalye kung ano ang maaaring ma-access ng bawat role.

Kinikilala ng Halo ang dalawang value ng role: User at Admin (hindi case-sensitive). Walang native na paraan ang Okta para tukuyin ang mga role sa Authorization servers. Kailangang idagdag ang mga role claim upang maipasa ang mga role ng user/client sa access token.

Mga role ng Portal SSO (`roles` claim)

Ginagamit ang claim na ito ng Portal upang matukoy kung aling mga page at feature ang available sa user. Inirerekomenda naming gumamit ng mga pangalan ng group na partikular sa Halo sa halip na mga generic na group na User o Admin, na maaaring sumalungat sa ibang mga application sa iyong Okta organization.

Gawin ang mga group sa Okta. Pumunta sa Directory -> Groups at gumawa ng:
- Halo_User
- Halo_Admin
I-assign ang mga user sa naaangkop na grupo.
Pumunta sa tab na Claims ng authorization server at gumawa ng roles claim na nagsasalin ng mga pangalan ng grupo sa mga halaga ng role ng Halo:
- Pangalan: roles
- Isama sa uri ng token: Access Token
- Uri ng value: Expression
- Value:
```
isMemberOfGroupName("Halo_Admin") ? "Admin" : isMemberOfGroupName("Halo_User") ? "User" : ""
```
- Isama sa: Any scope

Tandaan: Gumagana lamang ang function na isMemberOfGroupName() sa mga flow na may user context (hal., Authorization Code). Hindi ito naaangkop sa mga flow na Client Credentials (machine-to-machine).

Mga API role (`role` claim)

Ginagamit ang claim na ito ng serbisyong API-Access upang pahintulutan ang mga operasyon. Dahil ginagamit ng mga API client ang Client Credentials flow (walang user context), hindi naaangkop ang mga expression ng membership sa grupo. Sa halip, i-map ang client_id sa isang halaga ng role.

Pumunta sa tab na Claims ng authorization server at gumawa ng role claim:
- Pangalan: role
- Isama sa uri ng token: Access Token
- Uri ng value: Expression
- Value:
```
(app.clientId == "<your-api-client-id>") ? "Admin" : "User"
```
- Isama sa: Any scope

Tandaan: Palitan ang <your-api-client-id> ng client_id ng iyong API Services application. Magdagdag ng mga karagdagang kondisyon para sa maraming API client, hal.:
(app.clientId == "<client-1>") ? "Admin" : (app.clientId == "<client-2>") ? "Admin" : "User"

Mga susunod na hakbang

Kapag na-configure na ang authorization server, magpatuloy sa pag-set up ng isa o pareho sa mga sumusunod:

Halo Portal SSO - i-configure ang Okta bilang identity provider para sa Halo Portal
Halo API Bearer Authentication - i-configure ang Bearer token authentication para sa Halo API

Kasama sa bawat gabay ang pag-configure ng access policy sa authorization server na ito para sa kani-kanilang client.

Mga Kinakailangan​

Gumawa ng authorization server​

Magdagdag ng custom scope para sa access sa Halo API​

I-set up ang claims​

Tukuyin ang mga role​

Mga role ng Portal SSO (roles claim)​

Mga API role (role claim)​

Mga susunod na hakbang​