Skip to content

Inter-Service Communication

File Access Manager uses SSL communications for all its deployed services.

SSL communications use server and client certificates which, by default, are self-signed and created when each service is installed. While the operating system may not trust these certificates, File Access Manager components do trust them.

The table below lists the relationships among the services and clients.

Service Clients Default Port
Agent Configuration Manager Activity Monitor
Event Manager
Central Data Classification
Central Permissions Collector
Data Classification Collector
Permissions Collector
Collector Installation Manager		 8000
Event Manager User Interface
Central Data Classification
Scheduled Task Handler
Central Permissions Collection
Web Server		 8001
Reporting Service User Interface 8006
User Interface File Access Manager Administrative Client 8005
Workflow User Interface 8008
Elasticsearch Event Manager
Reporting Service
Scheduled Task Handler
User Interface
Web Server
Activity Analytics		 9200
Elasticsearch Elasticsearch 9300
RabbitMQ Central Permissions Collector
Central Data Classification
Permissions Collector
Data Classification Collector
Activity Monitor
Event Manager		 5671
RabbitMQ Schedule Task Handler 15671
Activity Analytics None 8010

It is a best practice for all components to be in a safe, secure network, behind firewalls, even though SSL secured communication is enabled.

Using Trusted Certificates

Administrators can provide their own certificates for the server services only. To be trusted, server certificates must conform to the following guidelines:

  • Certificates are signed by a commercial or in-house CA that is trusted by all servers in the organization.
  • Certificates are issued to each server hosting one of the Windows Communication Foundation (WCF) hosting services.
  • Certificates include the server name as it is to be used by File Access Manager - whether it is a short name or a Fully Qualified Domain Name (FQDN) in the Subject or in the Subject Alternative Names list.
  • At minimum, the certificate must have the following extensions defined:
    • Key Usage: Digital Signature, Key Encryption
    • Enhanced Key Usage: Server Authentication, Client Authentication

Note

See the installation guide for a detailed description on using local certificates for File Access Manager and configuring the website to use SSL.

OAuth Support

File Access Manager offers full support of OAuth 2.0 Authentication for all cloud connectors.

All monitored applications support Application Based, Client Credentials authentication.

The AzureAD identity collector leverages service account User-Flow authentication, offering support for enhanced security measures such as MFA requirements.

Follow the instructions on the specific application connectivity deployment guide for more details.

Supported applications:

  • SharePoint Online
  • Exchange Online
  • DropBox
  • Box
  • Google Drive
  • OneDrive

Preliminary Setup

  1. An app is registered in the provider's app management console. See description per application in the relevant connector installation guide.

  2. App registration generates a set of identifiers: ClientId and ClientSecret. These identify the app uniquely and are used for issuing token requests.

    App registration includes the definition of a redirect URI that is used for user redirection upon completion of the authentication process.

  3. Upon successful authentication and consent, the provider will redirect the user; the redirection URI will be appended with a user authorization code in the URL query string.

Authentication Flow

  • An end user browses to a special App Authorization URL - this is typically a credentials' input form at the provider's website.

  • The end user logs in to the provider with one of the following outcomes:

    • Login Failure - The end user is redirected to the app's redirect URI with an error message in the query string.

    • Login Success - The end user is presented with a consent form that lists the permissions that the app is requesting. There are two possible outcomes:

      • Consent Declined - The end user is redirected to the app's redirect URI with an error message in the query string.
      • Consent Given - The end user is redirected to the app's redirect URI with a user authorization code in the query string.

  • A web page, or some other code, issues a token request using the user authorization code. This code is active for roughly 30 seconds.

  • The provider responds with a token set.
  • The access token can be used to issue requests to OAuth2-enabled services exposed by the provider.

OAuth2 Token Management - OAuth2 Minisite or OAuthWebsite

The OAuth2 minisite is deployed to ease the management of File Access Manager's interface to OAuth2-based services. The minisite enables storage of all provider-specific configuration in a unified location, thus enabling us to modify it from a single location.

The minisite provides the following:

  • Storage of global info, including provider-specific information:

    • ClientId
    • ClientSecret
    • URL for user authentication
    • URL for token requests
    • Scope, for providers that allow dynamic permission requests

  • Handling of OAuth2 flow operations:

    • UserRequest.ashx
      Redirecting the end user to the appropriate provider's website to start the authentication process.

    • Callback.aspx
      The target of Redirect URI, extracting the User Authorization Code or error message from a query string and displaying it in a user-friendly format.

    • AccessToken.ashx
      Encapsulating initial requests for access tokens, exchanging a User Authorization Code for a Token Set.

    • RefreshToken.ashx
      Encapsulating requests for token refresh, exchanging a Refresh Token for a new Token Set.

Agent Configuration Manager - TokenRefreshServer

This central service is responsible for refreshing all OAuth2 tokens automatically and providing a token retrieval interface for other File Access Manager components.

The logic described here is implemented in: AgentConfigurationManager\src\TokenRefreshServer.cs

  • Interface Operations

    • Upon token request, the requested token is sent as a response.
    • If no such token is loaded, the service attempts to load it from the database.

  • Automatic Operations

    • Upon startup, the service loads all available tokens from the Business Application Management (BAMs') (application's) configurations.
    • Whenever a token is approaching expiration, it is automatically refreshed and updated in the database.

    • If a token refresh fails, the token is removed from the memory cache:

      • This mechanism allows automatic release of expired or failed tokens and protects the service from endless refresh attempts.

        Note

        Failed Refresh - there are various reasons for a failed refresh, such as modified or deleted consent user, expired app key, network errors, etc.

      • A token reload and refresh is re-attempted if or when it is requested again through the ACM token management interface.

  • TokenRefreshServer is the only File Access Manager component that executes token refresh operations:

    • Provides a solution for security mechanisms where upon refresh, all tokens are canceled except for the latest.
    • A centralized point for token management makes for easier logging, debugging, and troubleshooting.