This chapter describes how to keep Oracle Managed File Transfer and its embedded FTP and sFTP servers secure.
This chapter includes the following sections:
Note:
If a user’s permissions have changed when the user is already logged in, the changes will be effective only on the next login. Once a user is authenticated, the permissions of the user will not change until the user logs out and logs in again. This is applicable for all the console, WLST, RESTful, and embedded server operations such as deploy, enable/disable, import/export or read/write embedded server operations.You configure Oracle Managed File Transfer users and assign them to groups in the Oracle WebLogic Server Administration Console.
Note:
Oracle Managed File Transfer interacts with Oracle Enterprise Scheduler Service through the OracleSystemUser
. Do not delete this user. If you do, clicking add schedule in a transfer configuration will result in an OracleSystemUser does not exist
message, and Schedule Details may be blank in monitoring reports. For more information about transfer schedules, see Setting Up Schedules.
The steps for this process are:
For complete details, see Create Users and Add Users to Groups in the Oracle WebLogic Server Administration Console Online Help.
Users log in to the Oracle Managed File Transfer console using the name and password assigned to them through the process described in Configuring Users. The Oracle Managed File Transfer page on which the user starts depends on the user's group:
Administrators start on the Administration page.
Deployers start on the Designer page.
Monitors start on the Monitoring page.
A user assigned to both the Deployers and Monitors groups starts on the Designer page.
Table 8-1 lists the roles, groups, and permitted actions for user access to the MFT console. Console access is based only on roles. Embedded server access roles and groups do not determine console access.
Table 8-1 MFT Console Roles, Groups, and Permissions
Role | Groups with Role | Console Actions Permitted |
---|---|---|
MFTAdmin |
Administrators, OracleSystemGroup |
Import, Export, Purge, Design, Deploy, Monitor, Resubmit, Pause-Resume, Retry, Disable, Enable, StartES, StopES (all actions) |
MFTMonitor |
Monitors |
Monitor, Resubmit, Pause-Resume, Retry, Disable, Enable, StartES, StopES |
MFTDesigner |
Deployers |
Design, Deploy |
You can grant users access to embedded FTP and sFTP server directories.
To use WLST to configure embedded server user access, see Oracle Managed File Transfer Utilities and MFT Embedded Server Commands in WLST Command Reference for SOA Suite.
The steps for this process are:
On the left pane of the Administration page, click the arrow to the left of Embedded Server.
The Ports and User Access items appear.
Click User Access.
The Embedded Server User Access tab opens.
Select User, Group, or Role, then type a user, group, or role name in the text field. You must type at least three letters. Any matches are displayed below the text field. Click the match you want to add.
You configure users, groups, and roles using the process described in Configuring Users.
Note:
If Enable screen reader mode is selected in Accessibility Preferences, you must type the full user, group, or role name. See Setting Language_ Time Zone_ and Accessibility Preferences for more information.
Click the Add Folder (+) icon.
The user's default folder is added to the table with Set As Home Folder selected.
To add other folders, click the Search icon.
Type a directory under which to search in the Available Folders text box.
Click the arrow to the right of the Available Folders text box.
Subdirectories of the search directory are displayed.
Click the arrow to the left of a directory to display further subdirectories.
To select a directory, check its box.
Click Add Selected.
Select Set As Home Folder to assign a different home folder. This is optional.
If Set as Home Folder is selected, the user is place in the Home Folder when they log on to the embedded server. If the home folder does not exist, it is created at login.
Set the following permissions for each row. To set a permission for all rows, check or uncheck the box in the column header.
Access Subfolders: Applies the same permission settings to all subfolders.
Read: Allows viewing of file contents.
Write: Allows modification of file contents.
Delete: Allows file deletion.
List: Allows viewing of directory contents.
Click Save.
To undo all permission changes for a specific user since the last Save, click Reset All. To undo all changes for all users since the last Save, click Revert.
Table 8-2 lists the groups and default permitted actions for user access to MFT embedded server directories. Console access roles and groups do not determine embedded server access.
Table 8-2 MFT Embedded Server Groups and Permissions
Group | Members | Actions Permitted | Additional Notes |
---|---|---|---|
Administrators |
Any Enterprise user. By default the user named weblogic is a member. |
Read, Write, Delete, List (file operations) createDir, renameDir, deleteDir, changeDir (directory operations) |
By default all permissions are granted to any member. |
MFTESAdmin |
Any Enterprise user. By default the Administrators group is a member. |
Read, Write, Delete, List (file operations) createDir, renameDir, deleteDir, changeDir (directory operations) |
This group is specifically for granting access to MFT embedded servers. By default all permissions are granted to any member. |
OracleSystemGroup |
Any Enterprise user. By default the user named OracleSystemUser is a member. |
Read, Write, Delete, List (file operations) |
Using this group for access provisioning is not recommended, because this group is intended for internal applications and system management. |
Other preexisting groups |
Any Enterprise user. |
Read, Write, Delete, List (file operations) |
Examples of these groups are Monitors and Deployers. These groups and users belonging to them are listed in the Embedded Server User Access tab. |
User-created groups |
Any Enterprise user. |
Read, Write, Delete, List (file operations) |
These groups and users belonging to them are listed in the Embedded Server User Access tab. |
User-created roles |
Any Enterprise user or group. |
Based on member groups. If a role has the Administrators group as a member, all operations are allowed. Otherwise only file operations are allowed. |
There is no preexisting role for embedded server access provisioning. You can create a role, assign members, and provision access. |
You can grant users, groups, and roles access to the payloads of transfers with these characteristics:
A SOAP, SOA, Service Bus, or ODI target type
A Delivery Method value of Reference
A Reference Type value of FTP
If you grant no specific access, then all users, groups, and roles have access to the transfer payloads.
The steps for this process are:
For more information about configuring transfers, see Configuring a Transfer.
Secure embedded servers are of two types: sFTP (SSH-FTP) or FTPS (FTP over SSL).
The embedded servers support the following protocols: FTP RFC959, FTP RFC2228, sFTP, FTPS, SSH-2, TLS 1.1, and TLS 1.2.The SSH-1 protocol and SSHD (secure shell) are not supported.
Table 8-3 lists the sFTP embedded server settings related to security. These settings are on the Administration page, Embedded Servers tab, and sFTP subtab. After changing any of these settings, you must Stop and Start the sFTP server to activate the settings.
Table 8-3 sFTP Embedded Server Security Settings
Setting | Description |
---|---|
Authentication Type |
Specifies the authentication type: Password (default), Public Key, or Both. |
Host Key Alias |
Specifies the alias of the SSH private key for authentication. To create SSH keys, see Configuring the SSH Keystore. |
Table 8-4 lists the FTP embedded server settings related to security. These settings are on the Administration page, Embedded Servers tab, and FTP subtab. After changing any of these settings, you must Stop and Start the FTP server to activate the settings.
Table 8-4 FTP Embedded Server Security Settings
Setting | Description |
---|---|
Plain FTP |
Enables plain FTP, without Implicit or Explicit SSL support, on the FTP server. You can enable implicit or explicit SSL support, or both, in addition to plain FTP. The default is enabled (checked). |
Implicit |
Requires the client to immediately challenge the FTPS server with a TLS/SSL |
Explicit |
Allows clients to explicitly request that the FTP server encrypt the session and mutually agree to an encryption method. This is known as explicit FTPS or FTPES. Explicit mode is legacy-compatible, so plain FTP clients can still connect to the FTP server. Common commands for invoking FTPS security include |
Client Authentication |
Specifies the level of client authentication: Need, Want, or None. Applies only if Implicit or Explicit is checked.
|
Protocol |
Specifies the security protocol: TLS (default) or SSL. Applies only if Implicit or Explicit is checked. |
Cipher Suite |
Specifies the cipher suites to use. To use all available cipher suites, check All. Checking none uses a default list. Applies only if Implicit or Explicit is checked. |
Certificate Alias |
Specifies the alias of the SSL private key for authentication. Applies only if Implicit or Explicit is checked. To create SSL keys, see Configuring the SSL Keystore. |
Note:
The message shown below is not an issue and is information logged to indicate that the FTPS service will not be started when there is no valid port available. This error information is not shown when implicit FTPS service is enabled.
{APP: mft-app] [partition-name: DOMAIN] oracle.mft.COMMON.<MFTServer.initFTPServer>:Invalid value for FTPS Port: [-1]. FTPS Service will fail to start.
You can integrate the Oracle Managed File Transfer console URL with Oracle Access Manager 11g to achieve single-sign-on with other Enterprise web applications.
For general information about installing and configuring Oracle Access Manager, see "Configuring Oracle Access Manager (OAM)" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal.
To protect the MFT console URL, follow the steps described in "Configuring the WebLogic Server Administration Console and Enterprise Manager for OAM" in Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal, except specify /mftconsole /mftconsole/* /mftconsole/.../*
as the Resource URL.
You can encrypt or decrypt a file that is being transferred. For more information, see Encryption and Decryption at the Source or Encryption and Decryption Preprocessing.
For encryption, you must reference the public PGP key alias. For decryption, you must reference the private PGP key alias.
To set up PGP keys and key aliases in the Oracle Managed File Transfer keystore, see Configuring the PGP Keystore.
Oracle Managed File Transfer uses SSL and SSH keys for embedded server security and PGP keys for message encryption. To manage keys in the Oracle Managed File Transfer keystores, use the Oracle WebLogic Scripting Tool (WLST) and the Oracle Managed File Transfer console, described in the following sections:
You can use the MFT WLST keystore management commands to generate, import, export, delete, list, and update SSL, SSH, and PGP keys. For more information, see the WLST Command Reference for SOA Suite.
Note:
SSL keys in binary (DER) format are not supported. Use keys in BASE64 (PEM or CER) format. You can convert key formats using the openssl
command.
Key lengths greater than 1024 bit are supported. However, there are some export restrictions on key lengths greater than 1024 bit. These restrictions are mostly specified at the JRE level in the JAVA_HOME
\jre7\lib\security
directory.
Note:
To create additional keystores, you can use WLST commands or the Oracle Enterprise Manager Fusion Middleware Control console. See Managing Keys and Certificates with the Keystore Service in Securing Applications with Oracle Platform Security Services, Managing Keystores, Wallets, and Certificates in Administering Oracle Fusion Middleware, and Managing the Credential Store in Securing Applications with Oracle Platform Security Services for more information about Fusion Middleware Control.
The default keystore is used for storing Oracle MFT SSL keys and certificates. To configure the default keystore, use WLST and the Oracle Managed File Transfer console.
The steps for this process are:
To configure the SSH keystore, use WLST and the Oracle Managed File Transfer console.
The steps for this process are:
To configure the PGP keystore, use WLST and the Oracle Managed File Transfer console.
Note:
If a payload is encrypted by a PGP tool outside of MFT using a key length or algorithm that is restricted, MFT decryption will fail. These restrictions are mostly specified at the JRE level in the JAVA_HOME
\jre7\lib\security
directory.
The steps for this process are:
You can enable audit logging for Oracle Managed File Transfer using Oracle Enterprise Manager Fusion Middleware Control or the Oracle WebLogic Scripting Tool (WLST).
To generate reports of audit data, see Using Audit Analysis and Reporting in Securing Applications with Oracle Platform Security Services.
The steps for this process are:
For more information about WLST commands for audit policies, see Manage Audit Policies with WLST in Securing Applications with Oracle Platform Security Services.
Oracle Managed File Transfer supports securing web service sources and targets with Oracle Web Services Manager (OWSM) policies. Web service sources and targets include those of type SOAP, SOA, Service Bus, and ODI.
Note:
WS-Security compliant policies are not supported.
You can attach one policy file per source or target. The policy file holds the attached policies and overridden attributes.
You can attach policies globally using Oracle Enterprise Manager Fusion Middleware Control or the Oracle WebLogic Scripting Tool (WLST). You can attach policies locally using the MFT console or WLST.
Web services security can be divided into the following parts:
Design time — when policies are attached and registered for the source or target.
Runtime — when the policies are enforced upon invoking the secured source or target.
Life cycle — how policies are managed regarding the life cycle of the source or target.
This section includes the following topics:
How you attach a policy depends on whether the policy is inbound (for sources) or outbound (for targets). In addition, some client policies require credentials.
Some client policies, such as the user name token policy, require credentials. Before you can attach such a policy using Oracle Enterprise Manager Fusion Middleware Control, you must create a map and key. For more information, see Managing the Credential Store in Securing Applications with Oracle Platform Security Services.
The steps for this process are:
You can create a policy set and attach a policy for a source. For more information, see Managing Web Service Policies with Fusion Middleware Control in Securing Web Services and Managing Policies with Oracle Web Services Manager.
The steps for this process are:
You can create a policy set and attach a policy for a target. For more information, see Managing Web Service Policies with Fusion Middleware Control in Securing Web Services and Managing Policies with Oracle Web Services Manager.
The steps for this process are:
Using WLST, you can attach a policy to all web service endpoints in Oracle Managed File Transfer.
The steps for this process are:
Start WLST using the steps described in Running WLST Commands.
Use the following WLST commands to create and attach a policy set:
beginRepositorySession()) createPolicySet('mft', 'ws-service', 'Domain("*")') attachPolicySetPolicy('oracle/wss_username_token_service_policy') validatePolicySet() commitRepositorySession() displayPolicySet('mft')
The wss_username_token_service_policy
is an example. You can attach a different policy.
Exit WLST using the steps described in Running WLST Commands.
You can also attach a policy to a specific web service endpoint, either a source or target.
The steps for this process are:
For more information about WLST commands for managing policy sets, see Policy Set Management Commands in WLST Command Reference for Infrastructure Components.
You can attach a policy to a specific web service endpoint, either a source or target.
The steps for attaching a policy are:
Start WLST using the steps described in Running WLST Commands.
Use the following WLST commands to create and attach a policy set:
beginWSMSession() listWSMPolicySubjects('mft-app') selectWSMPolicySubject('/weblogic/soainfra/mft-app', '#SOAPSource', 'WSService({http://xmlns.oracle.com/fmw/mft/soap}MFTService_SOAPSource#MFTServicePort)') attachWSMPolicy('oracle/binding_authorization_denyall_policy') attachWSMPolicy('oracle/wss_username_token_service_policy') previewWSMEffectivePolicySet() commitWSMSession()
The SOAPSource
is an example. You can create a policy set for a different source or target.
The wss_username_token_service_policy
is an example. You can attach a different policy.
Exit WLST using the steps described in Running WLST Commands.
The steps for detaching a policy are:
For more information about WLST commands for managing policy sets, see Policy Set Management Commands in WLST Command Reference for Infrastructure Components.
For a source, the sending user must specify the policy and its required credentials with the file to be transferred. Otherwise the file transfer will not succeed.
For a target, the receiving user does not need to specify the policy. This is the responsibility of the sending user in the transfer. However, if the sending user does not specify the policy attached to the target and its required credentials, the file transfer will not succeed.
Credentials that the policy requires can include a username, password, certificate, or other security information. See Managing Policy Credentials for more information.
A policy file is persisted in the MFT metadata store (MDS) and follows the exact life cycle pattern of its parent source or target artifact, including the version.
Create an artifact, and the policy file is created in the MDS and referenced by the artifact.
Deploy an artifact, and the policy file is automatically registered in OWSM.
Undeploy an artifact, and the policy file is de-registered.
Enable an artifact, and the policy file is automatically registered in OWSM.
Disable an artifact, and the policy file is de-registered.
Delete an artifact, and the policy file is deleted from the MDS.
Export an artifact, and the policy file is exported and linked to by the artifact export file.
Import an artifact, and the linked policy file is also imported.
After you attach policies globally or locally, you can use WLST to verify that these policies are registered in the OWSM repository as part of the effective policy set.
The steps for this process are:
For more information about the WLST commands for policy subjects, see Policy Subject Commands in WLST Command Reference for Infrastructure Components.
For general information about the OWSM repository, see Overview of Web Services Administration in Administering Web Services.
Create a SSL only domain in Oracle Managed File Transfer.
Enabling SSL only Domain
Follow the steps below to set up Oracle MFT in an SSL only WebLogic domain.
Enable the SSL listening port at the time of domain creation, in case of new domains.
For existing domain, extend the domain and select the SSL listening port.
Start the AdminServer and disable the non-SSL listening port of the managed Server and AdminServer.
Start the managed server.
Invoking Webservice over SSL (HTTPS service)
Follow the steps below to invoke the SOA/SOAP targets over HTTP SSL protocol.
Export the SSL certificate of remote SSL webservice, for example, from Web browser to File.
jdk_home/jre/lib/security/cacerts
/wlserver/server/lib/cacerts
EM > Security > Keystore > System > Trust store, CA store
Restart the server.
Configuring remote SSL FTP server
Follow the steps below to connect from a Remote FTP(S) Source or Target to a remote FTP Server. The remote FTP Server can be non-MFT FTP Server, or it could be MFT Embedded FTP Server within another deployment of MFT.
Export the trusted certificate used for remote SSL FTP server to a file using appropriate tools. In case of MFT FTPS remote server, do it via WLST with below command:
svc.exportKeyStoreCertificate(appStripe='<stripe>',name='<store>',password='<storePassword>',alias='<certalias>',type='Certificate',filepath='<filePath>')
Import the trusted certificate to MFT using the below WLST command:
svc.importKeyStoreCertificate(appStripe='<Stripe>',name='<Store>', password='<StorePassword>',alias='<certAlias>',keypassword='<keyPassword>',type='TrustedCertificate',filepath='<filepath>')