Axway secure transport password#
When exporting the key-pair, do add password and do make it longer than 8 characters. In result, you will not be able to obtain the private key anymore and a new key-pair would be needed. If the key-pair is not saved at this point, SecureTransport will delete the private key at the end of the generation and will keep the public key only. Do this now and store the exported file to be sent to your user later. When the key-pair is generated, you will be asked to store it as a backup. The exact page where this is to be done is Certificates → Login Certificates. In this approach, the key pair is generated in ST, under the respective account, which the user will use to connect to ST. The second option is the recommended one, since the partner will be the only party holding the private key at all times, while this is not the case in the first option. There are two common ways to get a key-pair for the authentication - generate them in ST, or obtain them from the partner who is going to connect to ST. In the scenario where a user connects to SecureTransport, the user is the client (holds the private key), and ST is the server, holding the public key. Using this key, the server is able to verify that the presented private key is part of the same key-pair and the authentication is successful.Īs a rule of thumb, only one person should have access to the private key, which is why it is recommended that the user creates the key-pair and sends the public part to the server to be imported and used for the authentication. SSH key authentication, contrary to the popular belief, requires that the client (user) holds the private key, while the server holds the corresponding public key.
Axway secure transport how to#
This can be done by an experienced DBA and the ST application can be online at the time.This article gives an example on how to set up public key (SSH) authentication for users, connecting to SecureTransport. To shrink the database in this scenario, you can use the SQL script attached to this article ( script_to_shrink_segments.sql).Īfter the tables are shrunk it will be possible to decrease the size of the data files. Oracle database does not support shrinking SecureFile LOBs so generally the Oracle community does not recommend the usage of high values for the undo_retention database parameter in combination with SecureFiles to avoid space issues. This is by design - Oracle made them to grow only, not to shrink since the encryption type does not permit it. SecureFile LOBs however cannot be shrunk using a normal ALTER TABLE. If a row is updated several times within the undo_retention interval the same amount of old row images will be present in order to support potential undo transactions. The reason is that the undo data of LOBs is stored in the same tablespace. Secure File LOBs (LOB columns of non-partitioned tables in our scenario) may grow quite a lot when the undo_retention is high (and the database parameter db_securefile is set to PREFERRED or ALWAYS, for example when the database is 12c+). the application must be stopped on all cluster nodes).įor newer installation (where ST was installed using Oracle 12c or later) there is a specific shrink issue with the way Oracle stores SecureFiles. SecureTransport must not be using the database when the script is executed (i.e. Select 'ALTER TABLE '||TABLE_NAME||' DISABLE ROW MOVEMENT ' from user_tables where tablespace_name='ST_DATA' Select 'ALTER TABLE '||TABLE_NAME||' SHRINK SPACE ' from user_tables where tablespace_name='ST_DATA' Select 'ALTER TABLE '||TABLE_NAME||' ENABLE ROW MOVEMENT ' from user_tables where tablespace_name='ST_DATA'