- 1. Introduction
- 2. About Data Gateway
- 3. Key Features
- 4. Glossary
- 5. System Requirements
- 6. Application Access
- 7. Roles
- 8. Dashboard Reports (Statistics)
- 9. Cloud Configurations
- 10. Access Management
-
11. Endpoint Management Module
- 11.1 Create Endpoint
- 11.2 Manage Endpoint
-
11.3 Protocols
- 11.3.1 FTP (File Transfer Protocol)
- Pull-Push
- Push-Pull
- Push–Push Scenario
- 11.3.2 FTPS (FTP Secure)
- Pull-Push
- Push-Pull
- Push-Push Scenario
- 11.3.3 SFTP (SSH File Transfer Protocol)
- Pull-Push
- Push-Pull
- Push-Push Scenario
- 11.3.4 API Based File Transfers
- 11.3.4.1 Pull-Push
- 11.3.4.2 Scenario: File Transfer through API, where You connect to Remote Server
- 11.3.4.3 Scenario: File Transfer through API, where Partner connects to Your Server
- 11.3.4.4 Push-Pull
- 11.3.5 AS2 (Applicability Statement 2)
- 11.3.5.1 AS2 Organizations
- 11.3.5.2 AS2 Endpoints
- 11.3.5.3 AS2 Relationships
- 11.4 GUID
- 12. File Management Module
-
13. Settings
- 13.1 Scheduler Configuration
- 13.2 PGP Manager
- 13.3 Application Configuration
- 13.4 Queue Management
- 13.4.1 Queue Management – Field Descriptions
- 13.4.2 Operational Summary
- 13.4.3 Key Benefits
- 13.5 Priority Handling
- 13.5.1 Priority Handling – Field Descriptions
- 13.5.2 Operational Summary
- 13.5.3 Key Benefits
- 13.6 Adapter Configuration
- 13.6.1 Adapter Configurations – Field Descriptions
- 13.6.2 Operational Behavior Example
- 13.6.3 Key Benefits
- 13.7 License Module
- 13.7.1 License Management – Field Descriptions
- 13.7.2 Operational Workflow
- 13.7.3 Key Benefits
- 14. Data Gateway Components
-
15. Connectivity and Authentication
- 15.1 Scenario: File Transfer through File Client, where Partner Connects to Your Server
- 15.2 Scenario: File Transfer through File Client, where You connect to Partner’s Remote Server
- 15.3 Push-Push Scenario
- 15.4 Scenario: File Transfer through AS2, push to partner and push to gateway
- 15.5 IP Allowlist & Rate Limiting
- 15.5.1 IP allowlisting
- 15.5.2 Rate Limiting
-
16. SAML Authentication and Authorization with Okta
- 16.1 What is SAML?
- 16.2 What is SAML Used For?
- 16.3 How SAML Works
- 16.4 Configuring SAML Authentication and Authorization in Okta
- 16.4.1 Prerequisites
- 16.4.2 Steps to Configure SAML in Okta
- 16.4.3 Download Identity Provider Metadata
- 16.4.4 Application Configuration (application.yml)
- 16.5 User Management for IDP Users
- 16.6 Common Troubleshooting Issues
-
17. Alert Management
- 17.1 File Not Received (FNR) Alert
- 17.2 File Not Received (FNR) Alert Timing Options
- 17.2.1 FNR Current Day Minutes
- 17.2.2 FNR Current Day Hours Scenario
- 17.2.3 FNR Daily Days Scenario
- 17.2.4 FNR Daily Weekdays Scenario
- 17.2.5 FNR Weekly Between Scenario
- 17.2.6 FNR Weekly Day of Week Scenario
- 17.2.7 FNR Monthly Specific Day Scenario
- 17.2.8 FNR Monthly On Scenario
- 17.2.9 FNR Monthly Interval Check Scenario
- 17.2.10 FNR Quarterly Scenario
- 17.2.11 FNR Yearly Every Scenario
- 17.2.12 FNR Yearly On The Scenario
- 17.3 File Load Alert (FLA Alert)
- 17.4 Manage Alerts
- 18. Cloud-Cloud File Transfer
- 19. OAuth 2.0 Authentication
- 20. ICAP Integration
- 21. Data Gateway APIs
16. SAML Authentication and Authorization with Okta
16.1 What is SAML?
Security Assertion Markup Language (SAML) is an open standard that allows Identity Providers (IdP) to pass authentication and authorization credentials to Service Providers (SP). This enables Single Sign-On (SSO), where users can log in once and access multiple applications without needing to authenticate separately for each. SAML transactions use Extensible Markup Language (XML) to standardize communications between the IdP and SP. It acts as the bridge between authentication (verifying user identity) and authorization (granting appropriate access). The OASIS Consortium approved SAML 2.0 in 2005, which brought significant improvements over SAML 1.1, making them incompatible. Organizations use SAML to integrate Software-as-a-Service (SaaS) applications with their existing identity management systems while ensuring security and centralized access control.16.2 What is SAML Used For?
SAML simplifies authentication and authorization processes by allowing identity providers and service providers to operate independently while ensuring seamless access to resources. The key benefits include: • Centralized User Management: Identity provider handles authentication while service providers verify authorization. • Enhanced Security: Eliminates the need for multiple passwords, reducing the risk of breaches. • Seamless User Experience: Users log in once and gain access to multiple services. • SaaS Integration: Organizations can securely implement third-party applications without compromising authentication processes.16.3 How SAML Works
• User Accesses the Application: The user tries to access a SAML-enabled service provider. • Service Provider Requests Authentication: The SP redirects the user to the configured Identity Provider. • Identity Provider Authenticates the User: If credentials are valid, the IdP generates a SAML assertion. • SAML Assertion Sent to SP: The IdP sends the signed assertion to the SP. • User is Granted Access: The SP verifies the assertion and grants the appropriate level of access.16.4 Configuring SAML Authentication and Authorization in Okta
16.4.1 Prerequisites:
1. An active Okta account 2. Administrative access to Okta and the service provider application 3. Service Provider metadata (or SAML configuration details from the application)16.4.2 Steps to Configure SAML in Okta:
1. Create a SAML Application in Okta • Log into your Okta Admin Console.
• Navigate to Applications > Applications.
• Click Create App Integration.
• Select SAML 2.0 and click Next.
2. Configure General Settings
• Enter an application name (e.g., “DG App”). (Optional) Upload a logo and configure visibility settings and then click Next
3. Configure SAML Settings
• Enter Single Sign-On (SSO) URL and Audience URI (SP Entity ID) as mentioned below. Set Name ID Format to EmailAddress (or as required by the SP).
• (Optional) Configure attribute statements if additional user information needs to be passed.
• Click Next.
4. Assign Users and Groups
• Under Assignments, add the users or groups who should have access to the application.
• Click on ‘Add Person’, provide the user details, and click on ‘Save’. The user will receive a ‘Set Password’ link if the ‘I will set password’ checkbox is selected.
• To create a group, click on ‘Add group’, provide the name, and click on ‘Save’
After successfully assigning the application to the user and user can be able to see assigned application like mentioned below
16.4.3 Download Identity Provider Metadata
• Navigate to the application’s Sign On tab. • Find the Identity Provider Metadata URL or download the XML file
• Provide this metadata to the service provider for SAML integration.
16.4.4 Application Configuration (application.yml)
The SAML configurations need to be provided in the Data Gateway application configuration for deploying the application with SAML profile.
• SSO-URL: Redirect URL from IDP.
• IDP-Metadata: Identity provider metadata for getting authenticated.
• IDP-Registration-id: Application registration ID in IDP.
• IDP-Groups: Roles supported by PCM & Configured in IDP.
• Default-Role: App Default role.
• SSO-Role-Prefix: Role coming from IDP will come with prefix.
• JWT-Secret-Key: To generate token after successful authentication with secret key.
• JWT-Session-Expire: Token Session expire.
Attempt to log into the service provider(application)
• Once user provide valid okta related username and password
• Okta will route to the Data Gateway application
• Verify the SAML authentication flow using browser developer tools or Okta logs.
• Ensure users are authenticated and authorized correctly.
16.5 User Management for IDP Users
Users with super_admin privileges can access the entire application, including the Dashboard, Transaction Search, Endpoint Creation/Update, Alert Management, Cloud Configuration, and Settings. Please click here for more information about the roles and the modules accessible for the roles. In Access Management, external users such as OKTA users cannot create or manage user details. However, users with roles like file_operator or file_manager can be assigned endpoints, endpoint groups, and endpoint directories, but they cannot create, update, or manage any other user’s information.
This is different when the application is deployed without SAML. Refer here for more details on the Access Management for local authentication deployment.
In the screenshot below, the logged-in user with super_admin privileges can view all external users but does not have the option to modify user details.
The logged-in super admin user can view other users’ details but cannot edit them. Also, the logged-in user who has super_admin privileges, can assign partners and groups to file_manager users and partner directories to file_operator users.
16.6 Common Troubleshooting Issues
