|Web API||Logical Endpoint Name ||Endpoint /Resource ||Method||Short Description |
|Token||activation_token_endpoint||/token/v1/activation/tokens||POST, GET, DELETE||Management of activation-tokens.|
|password_reset_token_endpoint||/token/v1/passwordreset/tokens||POST, GET, DELETE||Management of password reset tokens.|
|username_token_endpoint||/token/v1/username/tokens||POST, GET, DELETE||Management of tokens to change a username|
|generic_token_endpoint||/token/v1/tokens||POST, GET, DELETE||Management of 'generic' tokens.|
|POST, GET, DELETE, PUT, PATCH|| Provisioning of end-user identities to iWelcome.
Note: /scim/users is an exception to the rule that a version is always included in the URL. In case of SCIM the standard prescribes that omitting the version must be supported: http://www.simplecloud.info/specs/draft-scim-api-01.html#api-versioning .
|POST, GET, DELETE, PUT, PATCH||Provisioning of ServiceDesk identities to iWelcome.|
|OAuth/OIDC||authorization_endpoint||/auth/oauth2.0/v1/authorize||OAuth2.0 authorization endpoint|
|token_endpoint||/auth/oauth2.0/v1/token||OAuth2.0 token endpoint https://tools.ietf.org/html/draft-ietf-oauth-discovery-06|
|introspection_endpoint||/auth/oauth2.0/v1/introspect|| Introspect endpoint as specified by RFC7662
|revocation_endpoint||/auth/oauth2.0/v1/revoke||Revocation endpoint as specified by RFC7009
|(well-known endpoint cannot be discovered)||/auth/oauth2.0/v1/.well-known/openid-configuration||Endpoint discovery endpoint as specified by https://tools.ietf.org/html/draft-ietf-oauth-discovery-10 and OIDC specifications.|
|token_info_endpoint||/auth/oauth2.0/v1/token-info|| Proprietary OAuth2.0 related endpoint.
⚠️iWelcome will stop support for TokenInfo endpoint by Q4 2020, thus it should not be used for new projects. It will be replaced with TokenIntrospect & UserInfo endpoints.
The domainURI is customer specific; it is agreed with iWelcome's customer. Typically it is a domain of the customer.
For a company named ONGO that could simply be www.ongo.com.
Sensible default for Brand is "idp1".
In case customers want to have multiple branded login pages within a single tenant, iWelcome configures multiple endpoints and the 'Brand' is shown in 2 locations in the SAML URLs like in the below examples:
For customers that choose to use iWelcome's multi-branding, the URLs may take various forms within a single tenant. Only one domain can be used per iWelcome tenant, but different subdomains and paths can be used.
The following table shows a few possibilities, using ONGO as an imaginary company having multiple lines of business. The specifics are agreed between iWelcome and the customer.
|<ENDPOINT-PREFIX> Value||Description/ Purpose|
|www.ongo.com||ONGO doesn't use iWelcome's multi-tenancy.|
|ONGO uses 2 brands, each brand has their own segment, so consumer end-users can have an identity in each of these.|
| Again, ONGO uses 2 brands, each brand has their own segment, so consumer end-users can have an identity in each of these.
In this case the <ENDPOINT-PREFIX>, uses the sub-domain to distinguish between segments.
|ONGO uses iWelcome's multi-styling capability. In this example, ONGO's applications make use of 2 different styles (look & feel): a red and a blue style.|
|ONGO uses 2 segments and two styles. The blue style is not used for the 'bicycles' segment.|
Note: The domainURI may not be the same for all endpoints in the case of multi-branding, since different styles may not be relevant for all endpoints (see table above).
Logical endpoint name as defined for endpoint discovery.
Convention: "xxx_endpoint" indicates it's a web-api