Authentication

Signing in using SSO Authentication

SSO Authentication

SAML2 SSO works a bit differently. The username and password are not entered in the WMS Cloud login page. The user instead clicks the “Login using SSO” button (which will be available after the SSO configuration has been setup by following SR process mentioned earlier). The page gets redirected to the Identity Provider’s login page where the user will login using their username linked to the IDP (this is stored in the “Alternate username” field in WMS Cloud). If the authentication succeeds, a token is returned to the WMS Cloud and the user is logged in to the application.

Note: SAML2 SSO backends that have been validated against WMS Cloud are Oracle IDCS and Azure AD. Technical Configuration for SSO.

OAuth2 Authentication

OAuth2 Authentication can be accessed by submitting an SR to My Oracle Support (MOS) for the setup. Oauth2 authentication can be used to login via Oracle Cloud WMS web UI or the RF handheld application. RF Handheld application authentication only works using local authentication or Oauth2. Due to technical reasons RF Handheld application cannot use SSO.

Please refer to the Administering Oracle Cloud Identity Management (Oracle IDCS reference) to understand the technical details.

Warehouse Management System Configuration for Alternate Authentication

Oracle Cloud WMS allows a single user to be external authentication enabled. There is no global flag to enable external authentication for all Oracle Cloud WMS users. Once the WMS Cloud environment has been setup for SSO or OAuth2 authentication, usernames in WMS Cloud have to be associated with a corresponding username in the external Identity Provider. This is the “Alternate username” field in WMS Cloud and must have the following format: <username>@<domain>

WMS Cloud users can be created/configured from the Users screen or by uploading a User Excel file from the Input Interface screen. It is possible to have some WMS users be locally authenticated, and others externally authenticated. It’s possible to have both SSO and OAuth2 backends configured for one customer.

Authentication

For Single Sign-On Authentication and OAuth2 Authentication please refer SSO and Alternate Authentication Setup Guide.

Staying Logged into the Service: End User Session Timeout

The Oracle Warehouse Management Cloud service has http session timeouts of 45 minutes for invalidating inactive user sessions. This means that any user after 45 minutes will have to re-authenticate when the session gets timed out, and then try to use a service resource.

Integration User Authentication

REST

Incoming REST API’s support the following authentication methods:

• basic auth (username and password)

• simple token based authentication

• OAuth2 token based authentication (for grant types ROPC and Authorization Code to obtain a token)

  There are also API related permissions to be setup within the WMS that controls the ability to read, modify or delete data. Outgoing REST API’s support only basic auth. Outgoing touch points can also be configured to send the payload to external SFTP or SFTP sites.

HTTP Request

The APIs may utilize the following five HTTP methods in order to provide users with Create-Read-Update-Delete (CRUD) functionality. Note that not all APIs support all methods.

GET: Return a read-only representation of the selected resource(s) in the response body.

HEAD: Read-only check for resource existence and/or modification. Does not return a response body. POST: Create resources or submit data to be processed by a resource operation.

PATCH: Modify existing resource(s).

DELETE: Remove/deactivate existing resource.

Supported Entities

The lgfapi entity module is used to access and modify OCWMS application data. It exposes specific methodologies for identifying subsets of data and obtaining their representations as well as allowing for the creation of certain resources. The entities supported and corresponding functionality will continue to be expanded through subsequent releases.

The entity module has a documenting feature that can be accessed via a GET request to the top-level (root) URL (.../ lgfapi/v10/entity/). This will return a sorted list of supported entities for the given lgfapi version and an accompanying base URL.

Each entity represents an object or combination of objects within OCWMS that is accessible via lgfapi. However, not all entities support all HTTP methods. Furthermore, these entities may share characteristics with their respective counterparts in other areas of the OCWMS application, but as a whole should be considered independent of other application functionality.

p

Application Permissions

Making a request to lgfapi not only requires user authorization, but also one or more of the CRUD application-level permission to access the supported HTTP methods. These are configurable in the user’s group-level permissions.

“lgfapi_read_access” – GET, HEAD

“lgfapi_create_access” – POST

“lgfapi_update_access” – PATCH

“lgfapi_delete_access” – DELETE

Note: this access is also required in order to run resource operations.

It is recommended to create dedicated user(s) with appropriate lgfapi permissions and different facility/company eligibility to protect the integrity of data. For instance, it is safe to give users read access but may not be appropriate to grant them permission to create or modify data.

The legacy API permission, “can_run_ws_stage_interface”, has been replaced by the new permission, “lgfapi_update_access”. This permission now applies to both lgfapi and the legacy APIs. For legacy API’s, this is the singular permission required to access all APIs. For lgfapi, this is one of several new permissions used to control user access.

Please refer to the Rest API Guide for more details.