This appendix provides an overview of common security risks for developers using the SL4000 web services API called StorageTek Library Control Interface (SCI), and information on how to address those risks.
SCI is a Web Services Definition Language (WSDL) based API that uses XML for data transmission and HTTPS for transport. SCI is bidirectional. For inbound SCI, the library is a server that responds to requests from a client program. Inbound SCI defines about 300 methods used to operate, configure, or monitor the library. Outbound SCI defines a set of about 25 methods that the library uses to send notifications. For outbound SCI, the library is the client for an external server.
Both the inbound and outbound interfaces provide similar security functionality:
Transport layer security with HTTPS using TLSv1.1 or TLSv1.2 protocols
Authentication with a username password token
Authorization for role based access control on inbound methods
Processing tools such as wsgen (Java code), gsoap (C and C++) or WSDL.exe (.net) can generate both client-side and server-side code from the WSDL file and its associated type files (XSD files). While you can manually construct the XML documents sent by a client of the inbound SCI interface or manually parse the XML documents sent by outbound SCI, Oracle recommends using a processing tool.
For the client-side code, the processing tool outputs a set of language-specific classes and callable methods that can directly be invoked by code that uses the interface. The terms ”class” and ”method” are used generically here. For server-side code, the processing tool outputs code that can be called by a client, in this case the library. Unlike the client-side code, the server-side code is incomplete and will typically have a line saying ”add your code here” in each generated method. The developer must add bodies to the generated methods.
Transport layer security provides privacy during data transmission by encrypting the message when the server sends it and then decrypting it when the client receives it. Both the client and the server have the contents of the message in clear text. The library uses the HTTPS protocol to provide transport layer security.
During initial installation, the library uses a default certificate (a pre-defined, self-signed x509 certificate) for HTTPS. During the library "hand off" process, you can choose to replace the default certificate with a library-specific, self-signed certificate or provide a third-party signed certificate. See the following for more information:
"Manage the Library's SSL/TLS Certificate for HTTPS" in the SL4000 Library Guide for instructions on how to update the library certificate.
"Certificates for HTTPS Interfaces" and "Handing-Off the Library to the Customer" in the SL4000 Security Guide for more information about the certificates.
For the inbound SCI interface, HTTPS is required. The library implements authentication using username password tokens. The user id and password appear in clear text, therefore HTTPS is required to avoid an eavesdropper on the network from reading the id and password from the messages in flight.
For the outbound SCI interface, HTTPS is optional. Oracle recommends using authentication and HTTPS on the outbound interface, however not all environments may require authentication. Creating an outbound SCI server (remember, the library is the client) without authentication does open the server up to numerous attacks.
Supported cipher suites are:
tls1_1: ECDHE-RSA-AES128-SHA
tls1_1: DHE-RSA-AES128-SHA
tls1_1: ECDHE-RSA-DES-CBC3-SHA
tls1_1: EDH-RSA-DES-CBC3-SHA
tls1_1: AES128-SHA
tls1_1: DES-CBC3-SHA
tls1_2: ECDHE-RSA-AES128-GCM-SHA256
tls1_2: ECDHE-RSA-AES128-SHA256
tls1_2: ECDHE-RSA-AES128-SHA
tls1_2: DHE-RSA-AES128-GCM-SHA256
tls1_2: DHE-RSA-AES128-SHA256
tls1_2: DHE-RSA-AES128-SHA
tls1_2: ECDHE-RSA-DES-CBC3-SHA
tls1_2: EDH-RSA-DES-CBC3-SHA
tls1_2: AES128-GCM-SHA256
tls1_2: AES128-SHA256
tls1_2: AES128-SHA
tls1_2: DES-CBC3-SHA
Both the inbound and outbound SCI interfaces use a username password token for authentication. Authentication is required for inbound and optional for outbound.
For inbound commands, the client must add a SOAP header to every message sent to the library to provide the username password token in clear text. Therefore, the client program must have access to and securely manage these credentials. The most secure method is to not store the credentials, but to have the client program prompt the user when necessary. A client program should avoid taking these values as command line arguments because system monitoring tools may display command line arguments. If the client program must store the credentials, do so in a secure manner, such as using a java wallet.
If you choose to implement authentication for the outbound interface, the server must extract the username and password from the SOAP header and use them to perform authentication.
The details of how to insert these values into the message or extract them from the message are specific to the programming language used on the client-side and the WSDL processor used to generate the stubs. The following is a sample inbound request:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:v1="http://v1_0_0.webservice.librarycontroller.summit.acs.tape.oracle/">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-98F0D229E2F29CEF1514779315276651">
<wsse:Username>username</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0
PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<v1:ping/>
</soap:Body>
</soap:Envelope>
All inbound SCI methods require authorization. Only certain roles can execute some methods. The roles are abbreviated as:
S1 (service), S2 (advanced service), S3 (escalation)
C1 (operator), C2 (user), C3 (admin)
I (installer)
All (viewer, all service roles, all customer roles, and installer)
The services (S) and customer (C) roles have increasing privileges. The method descriptions in Chapter 1, "Library Inbound Methods" list the lowest role that can execute the method. Higher privileged roles can also execute the command. For example, a method labeled "C2,S2" can be executed by C2 (user), C3 (admin), S2 (advanced service), or S3 (escalation).
A customer-created SCI program can only use the customer roles of Viewer, Operator, User, or Administrator. Developers should examine the method they intend to use and choose the lowest of the four available roles. Then library Administrator can create a library user with that role for the client program and then provide the id and password to the client program. For information on creating a library user through the GUI, see ”Add, Modify, or Delete a User” in the SL4000 Library Guide.
Outbound SCI is one of several forms of ”notification” provided by the library. Use the GUI to configure the outbound SCI clients (see "Configure the Library to Send Outbound SCI" in the SL4000 Library Guide). If the outbound SCI server will perform authentication, you must select HTTPS and provide an id and password. You cannot use authentication credentials if you select HTTP.