Authentication The process of verifying the identity or other attributes of a user, user device, or other entity. This is a prerequisite of authorization.
Authorization Access privilages granted to a user, program or process.
Confidentiality Information is not disclosed to users, user devices or processes unless authorized (i.e., Encrypt data to prevent interception)
Integrity The property whereby an entity has not been modified in an unauthorized manner. Ensuring information non-repudiation and authenticity
- Supported for Rest APIs and SOAP APIs
- API provider can use API Gateway for enforcing authentication on the API
- API Gateway policies can be configured so that API Gateway expects the clients to pass the authentication credential through transport headers
- Supported Authentication Schemes :
- HTTP Basic Authentication
- JWT
- Kuberos Token
- Oauth2 Token
- OpenID Connect
- Supported for Rest APIs and SOAP APIs
- the native API is protected and expects the authentication credential to be passed through transport headers
- API Gateway policies can be used to provide the credentials that will be added to the request and send to the native API
- Supported Authentication Schemes :
- Basic
- Kuberos
- NTLM
- Oauth2 Token
- JWT
- Alias
- Authentication to use on WSDL
- Identity & Authorize
- Inbound Auth - Message
- Cek WS username token
- when testing on SOAP:
- use authentication as basic Auth
- field the form basic auth
- on canvas input right clik choose add username token
- change basic auth to No Authentication
- Hit
- OAuth2 is a delegation framework that enables applications to obtain controlled access to user accounts
- It works by delegating user authentication to the service that hosts theu ser account, and authorizing third-party applications to access the user account.
- Functionality:
- Clients can access server resources on behalf of a resource owner
- Resource owners can authorize client to their resources without sharing their credentials
- Resource owners can limit scope and time of access
- OAuth2 Authentication Strategies in API Gateway Consumer Application are linked with OAuth2 Client Application on an OAuth2 Authorization Server
- One application can use different authentication mechnisms, but still be identified as the same Consumer Application
- Scope is a mechanism in OAuth2 to limit a client application's access to a user's account
- An OAuth2 token will always be issued for one or multiple scope(s)
- At runtime, the Resource Server can decide whether the scope(s) of the presented token is/are sufficient for accessing the requested resource
- In API Gateway as a Resource Server, each OAuth2 scope is mapped to one or multiple APIs
- OAuth2 scopes can also be mapped to API sub-scopes instead of full APIs
- Watch out: The term scope is used with two different meanings here: It can mean OAuth2 scope or API (sub-)scope
Use Case OAuth2 Grant Types Web-server apps Authorization code Browser-based apps, mobile apps Implicit Username/password access Password Application Access Client Credentials
- Each OAuth2 scope must be defined in the local Authorization Server in API Gateway
- click on Administration -> Security -> JWT/OAuth/OpenID -> local
- first setting up on section OAuth Configuration
- second on section OAuth Scopes add new scope example "bookstore"
- Each OAuth2 scope can be mapped to one or multiple APIs and/or API Scopes
- click on OAuth/OpenID scopes -> Map scope
- Select authorization server scope which was created on OAuth Scopes
- Select API Scope or Scope who want to mapping to this scope
- OAuth2 credentials are stored in a Consumer Application's Authentication Strategy
- A new Authentication Strategy can either point to an existing or create a new OAuth2 Client Application in Authorization Server
- to create new strategy on Application you can edit the application on tab Authentication click Create Strategy. you can create strategy more than one
- OAuth2 configuration parameters in an Authentication Strategy can be modified in Application Edit mode
When a registered user clicks on Request Access in API Portal:
- API Gateway will automatically create a new Consumer Application
- It will automatically add an OAuth2 Authentication Strategy to the Application
- The new Authentication Strategy will be linked with a newly created OAuth2 Client Application
- The new OAuth2 Client Application :
- Will be configured to support grant types Autorization code, implicit and Client Credentials
- Will be assigned to the scope(s) to which the API (and its API scopes) is (are) assinged
- Ketika consumer create new applications di api portal di API petstore, apigateway akan membuatkan satu applications dengan config grant type nya Autorization code, implicit and Client Credentials. dan application tersebut akan langsung di subscribe kan ke API petstore. ketika API petstore itu sudah punya OAuth Scopes (yg di buat di halaman administration) dan OAuth Scope itu sudah di buat Map scope nya ke API petstore maka application yg di request oleh consumer dari api portal tadi akan langsung menggunakan scope yg sudah di buat. jika API petstore belum di Map scope kan maka application yg di request oleh consumer lewat api portal tidak akan menggunakan scope.
- Within the Try API section, API Portal will list the user's applications registered for the API
- The user can select on of the listed applications
- API Portal provides support to get a new OAuth2 Token for the selected application
- Token name is requested
- All other properties needed for the request are pre-generated based on the application data in API Portal
- Authorization and/or access token requests are sent to API Gateway(dependinh on the selected grat type)
- In case of approval, the access token is generated and provided as Bearer token for the Authorization header of the request
Setting below on administration Extended settings
HTTP | HTTPS |
---|---|
set pg_oauth2_isHTTPS to false | set pg_oauth2_isHTTPS to true |
- You will request and use the refresh token to request a new access token when the original access token has expired. You will repeat this step for the OAuth2 grant types Authorization Code and Password. Note that refresh tokens are not supported for the OAuth2 grant types Client Credentials and Implicit.
- Kelebihan refresh token adalah, ketika owner credentials mau membolehkan orang lain untuk meng hit api dengan credential nya maka si owner credential tersebut cukup memberikan refresh token nya saja, tidak perlu memberikan client_id dan client_secret nya. refresh token tersebut bisa digunakan untuk meminta access_token token baru.
- JWT is a JSON-based open strandard for creating access tokens that assert a numbers of claims
- A server could generate a token that has the claim logged in as admin
- Server provides that to a client
- Client could use that token to prove that (s)he is in logged in as admin
- Token are designed to be
- Compatct, URL-safe, usable in web browser single sign-on (SSO)
- Typical claims
- Pass identity of authenticated users or applications between and identity provider and a service provider
- Token can be signed and encrypted
- Token can be validated locally by the service provider without contacting the identity provider
- Based on the JWT signature
- Tokens can include an expire date and time
JSON Web Token consist of three parts separated by dots (.) which are:
Header.Payload.Signature
(HEADER) eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
(PAYLOAD) >eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
(SIGNATURE) SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Go to https://jwt.io for creating, introspecting and debugging JWTs
- JWTs can support a wide variety of use cases for securely transmitting information between parties Main use cases for JWTs in the context APIs:
- Proving identity: JWT will include claims like name, address, email address, birthdate, link to profile picture etc -> User Token
- Applications can use these data to create a personalized user experience and request access to backend services on behalf of the user
- User does not have to share credentials with the application
- Proving access rights / user authorization: JWT will include claims describing the user's access level(e.g. user roles), IDs of the permitted applications and maybe the account IDs of the user in these system -> Access Token
- Applications can use the JWT to access backend services through APIs
- User does not have to share identity data or client credentials with the application
- Proving application authorization: JWT will include a claim identifying the authorized application, in addition it might include claims describing the application's session context, e.g the user who logged in -> Application Token
- Applications can use the JWT to access backend services through APIs
- Proving identity: JWT will include claims like name, address, email address, birthdate, link to profile picture etc -> User Token
- User
Share credentials with the identity provider and appoves the token request (for use Token and Access Token) - Service Provider
The server hosting the service. API Gateway is governing to native services throught the APIs with the respective policies - Client Application
Consumer application requesting access to a service on the Service Provider - Identity Provider
Ther server that issues the token, API Gateway can take this role, External Authorization Server are also supported
-
API Gateway can issue User Tokens and Access Tokens for API Gateway users:
- User Token: GET http(s)://host:port/rest/pub/apigateway/jwt/getJsonWebToken
- Access Token: GET http(s)://host:port/rest/pub/apigateway/jwt/getJsonWebToken?app_id=xxx
- User identification through HTTP Basic Authentication
- Tokens of both types will include subject claim ("sub") with the API Gateway username
- Access Token will include "app_id" claim with the application id
-
API Gateway can issue Application Tokens for API Gateway applications
- POST http(s)://host:port/gateway/security/getJsonWebToken
- Application identification throught any identifier
- Request payload can include JSON object with custom claims
- Token will include subject claim ("sub") with the application id and the custom claims from the request
-
API Gateway can validate all three Token types and authorize / identity an application based on any combination of standard or custom claims included in the token
-
Tryout JWT-protected APIs in API Portal with Access Token
JWT configuration must be defined in the local Authorization Server in API Gateway
Go to Administration then Security then JWT/OAuth/OpenID then Internal authorization servers then local
- JWT Configuration
Key Value Token issuer Infosys Algorithm RS256 Expiry duration (minutes) 360 Audience Consumer Keystore alias DEFAULT_IS_KEYSTORE Key alias ssos - In reality configuration you should not use DEFAULT_IS_KEYSTORE
- JWT claims are stored in a Consumer Application in claim sets
- Each claim set can contain multiple claims that must be met in order to authorize / identify the application
- We can use claims to getJsonWebToken
- We can use API access key to getJsonWebToken
- or both
how to allow authentication with many teams using basic auth without application registered ?
HTTP Basic Authentication
- API white this polices request basic auth for authorization, select application lookup condition with Global applications and DefaultApplication, then add Authorize User, you can select from List of User or List of Team or List of Group which was registered on API Gateway User Management