| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
 Previous |
 Next |
| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
Previous |
Next |
ORFM integrates with a TaxWeb Tax Rules, through the Retail Tax Integration Layer (RTIL) to take advantage of situations that may arise as a result of the Brazil tax legislations.
The communication between ORFM/RMS, the RTIL, and TaxWeb Tax Rules occurs through the Web Services. The Oracle Software Security Assurance (OSSA) program advocates that the Web Service communication should occur in a secure manner.
The different mechanisms of securing web services are:
Transport-level security, in which Secure Sockets Layer (SSL) is used to secure the connection between a client application and the Web Service.
Message-level security, in which data in SOAP message is digitally signed or encrypted.
Access control security, which specifies which users, groups, and roles are allowed to access Web Services.
OSSA mandates that sensitive data like passwords should be encrypted before storing into the database. Encryption/decryption is the approach adopted for securing data where the original data must be reconstructed from the encrypted data. The data is encrypted and decrypted using a key value and a specific algorithm.
The following functional processes in ORFM/RMS use the tax calculation in which integration is realized through secured Web Services:
Inbound Nota Fiscal validation
Outbound Nota Fiscal issuing
PO tax break up
Item creation (Purchase/Sales)
Freight Nota Fiscal
This chapter covers the following topics:
Transport-level security secures the connection between the client application and WebLogic Server with SSL. SSL provides secure connections by allowing two applications connecting over a network to authenticate the other's identity and by encrypting the data exchanged between the applications. Authentication allows a server, and optionally a client, to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.
Message-level security includes all the security benefits of SSL, but with additional flexibility and features. Message-level security is end-to-end, which means that a SOAP message is secure even when the transmission involves one or more intermediaries. The SOAP message itself is digitally signed and encrypted, rather than just the connection. And finally, you can specify that only parts of the message be signed or encrypted.
For access control security, specify the list of users, groups, or roles that are allowed to access a Web Service. Then, when a client application attempts to invoke a Web Service operation, the client authenticates itself to WebLogic Server, using HTTP, and if the client has the authorization, it is allowed to continue with the invocation. Access control security secures only WebLogic Server resources. This means that if you configure only access control security, the connection between the client application and WebLogic Server is not secure and the SOAP message is in plain text.
The user credentials you can use to invoke the Web Service from Oracle Retail applications (ORFM/RMS) are stored in an encrypted format. The user name and password which is provided at the client side is encrypted by using a database procedure with an algorithm initially and stored into the database. At the time of invocation another database procedure is used to decrypt the password and set the authentication parameters internally in the SOAP message. On the server side, the Web Service custom security policy (usernametoken) is attached to the Web Service method. The same user name and password is attached to the usernametoken policy on the server side. The user name profile tokens are the user name and password associated with a Web Service request and used for authentication and authorization.
Use the following procedure to test your Web Service security:
Configure the user name/password at the server side (WebLogic) and attach the user name/password to the usernametoken policy.
Using the encrypt package, store different encrypted user name/password to the database (retail_service_report_url table). The Web Service invocation fails if a wrong password is set up for the invocation.
