| Oracle® Retail POS Suite Security Guide Release 14.1 E54480-01 |
|
 Previous |
 Next |
Figure 1-1 shows an overview of Oracle Retail POS Suite security features.
The POS Terminals and mobile devices are located in the customer-facing areas of the store in proximity to both customers and employees. Physical security of the hardware is the responsibility of the retailer. Operational practices, like provisioning employees to appropriate application roles and shutting registers down when not in use, are also the responsibility of the retailer.
The In-Store processor is assumed to be in a restricted access resource, from both physical and computer user access standpoints. Access to the In-Store processor should restrict access to the operating and file systems. The retailer is responsible for making sure that other applications installed on the In-Store processor (ISP) do not compromise the Oracle Retail applications or severely impact the performance of the In-Store processor.
Securing the in store network is a responsibility of the retailer and is assumed to be compliant with PCI-DSS requirements for topology, wireless access, and WAN connections. The connection to the corporate data centers and the external credit authorizers also are assumed to follow PCI-DSS requirements for secured connections.
The general deployment of the POS Suite is distributed across the individual stores with applications deployed on central corporate servers as well. Each store has a set of registers running the Oracle Retail Point-of-Service Client application or devices running the Oracle Retail Mobile Point-of-Service application. These clients communicate with the Oracle Retail Point-of-Service Server application running on the ISP. Additionally, the ISP has an application server instance hosting the Oracle Retail Back Office application. These two server applications share a single database schema.
In the corporate data center, the POS Suite has two applications: Oracle Retail Central Office and Oracle Retail Returns Management. Oracle Retail Central Office provides corporate-level operations such as Store Systems user administration, parameter maintenance, and a central transaction repository for all the stores. Oracle Retail Returns Management is a centralized system designed to monitor and control the return of retail merchandise. Each application is hosted in an application server instance with access to a dedicated database instance.
For more information about secure deployment of each Oracle Retail POS Suite product, see each product's Installation Guide.
Security Guides for dependent applications are found at the following
web sites:
Oracle Database 12c Release 1:
http://docs.oracle.com/database/121/TDPSG/E17609-19.pdf
Oracle WebLogic 10.3:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/security.html
Oracle Retail Back Office and Central Office can only be accessed over HTTPS. HTTP protocol is disabled, and accessing these applications over HTTP is not possible.
To install a valid SSL Certificate on the application server, see the documentation for your installed application server. The use of the default SSL certificate shipped with the application server is not allowed because it renders the application prone to intrusion attacks.
|
Caution: Oracle Retail is not responsible for the PCI-DSS compliance of any product customization performed by a retailer, system integrator, or reseller. |
The relevant security features fall into one or more of the following categories. For information on these categories, see the following sections:
The protection of sensitive data during transit, processing, and storage is paramount. Sensitive data includes personally identifiable information such as credit card number, Social Security number, checking account number, and positive ID such as driver's license number.
The Oracle Retail POS Suite applications focus on protecting sensitive data. The framework used is extensible and should be able to be used to secure additional items, if desired.
In Release 14.1, Oracle Retail POS Suite is no longer considered a payment application because it does not store, process, or transmit credit card data. Instead, it integrates with third-party payment applications such as those provided by ACI or Servebase. These external applications handle all access to cardholder data and supply tokens for the Oracle Retail POS Suite applications to use in place of actual cardholder data.
Credit card track data, CVV values, PINs and encrypted PIN blocks are not read or stored by the Release 14.1 Oracle Retail POS Suite applications in transaction logs, history files, trace files, debugging and error logs, audit logs, database schemas, and tables, or database contents.
When implementing or extending the Oracle Retail POS Suite applications, you must take care to ensure that cardholder data does not enter the Oracle Retail POS Suite application footprint. Credit card data should be kept within the integrated third-party payment application and should not enter the Oracle Retail POS Suite application memory.
Steps that should be taken to ensure that cardholder data does not enter the Oracle Retail POS Suite application memory include the following:
Ensure that you integrate with a PCI-DSS compliant payment application.
When extending the Oracle Retail POS Suite applications, do not add functionality that reads or stores cardholder data. Instead, ensure that all credit card access is handled by the integrated payment application.
Although credit card data is not processed by the Oracle Retail POS Suite, other sensitive data, such as checking account number, is protected through encryption.
Cryptographic functionality is provided by integrating with a compliant enterprise key management application. Oracle Retail POS Suite applications are designed to easily integrate with such a key management solution.
Each application accesses the external key management application using an adapter that connects the application cryptography API with the API of the third-party vendor. The retailer or system integrator creates that adapter by implementing the encryption service interface. The interface provides the methods to encrypt and decrypt. This adapter is configured at installation time.
Access to the enterprise key management service is required by external applications that need to decrypt the data. Securing the external applications is the responsibility of the retailer or system integrator.
An operating system can reveal the contents of its memory, through virtual memory, a core dump, or a KCore file on Linux. By protecting sensitive data in system memory, sensitive data is protected from exposure. The Release 14.1 Oracle Retail POS Suite applications only decrypt data when necessary and overwrite and release memory as soon as it is no longer needed.
An additional layer of communication security is provided for Oracle Retail Central Office and Back Office. These applications require the use of a Secure Sockets Layer (SSL) to access them. SSL provides an additional layer of encryption and security of the information sent to and received from these applications.
Securing access to the application against malicious attacks and auditing secure events are accomplished with passwords, additional testing of web applications, and additional examination of source code.
Password policy settings are configured through the database. By default, the password policy is compliant with PCI-DSS section 8.2. For example, passwords must be changed at least every 90 days, be at least seven characters, and include both numeric and alphabetic characters.
|
Caution: You can change the password policy, but you must ensure the modified settings comply with PCI-DSS section 8.2. |
The Release 14.1 Oracle Retail POS Suite applications protect authentication passwords. There are no clear-text passwords available in the applications. Passwords are required for schema creation, data source connection, and application authentication, but these passwords are all protected.
|
Caution: If you create any authentication points or files that may exist on a server or client, ensure that you do not expose any password information in clear text. |
The Oracle Retail POS Suite web-based applications are subjected to additional testing and scrutiny. The applications are tested with tools designed to subject the applications to known attack methods in an effort to identify areas of vulnerability. In addition, the source code for all Oracle Retail POS Suite applications undergoes static code analysis.
Oracle Retail POS Suite maintains a team of individuals who are responsible for monitoring newly discovered security vulnerabilities to see if they affect the applications. Additionally, each release undergoes intrusion and penetration testing.
Product updates and patches are produced and tested by the Sustaining Engineering group at Oracle Retail and are made available to retailers through secure download through the My Oracle Support web site.
Oracle Retail POS Suite application development standards mandate that all code is peer reviewed before it is promoted to the code base. Retailers and system integrators who are customizing or extending any of the applications, should consider implementing their own security coding standards and review processes.
The Release 14.1 Oracle Retail POS Suite applications do not prevent the use of network address translation, port address translation, traffic filtering devices, anti-virus protection, or encryption. Also, they do not interfere with the installation of patches or updates. Due to the nature of subtle incompatibilities between application server implementations, retailers are advised to test the latest application server updates with the applications prior to putting those updates into production environments.
The Release 14.1 Oracle Retail POS Suite applications have various security features built in like timeouts for unattended applications, screen closing, and so on.
Oracle Retail Point-of-Service implements a uniform timeout of the application in 15 minutes when left unattended. In any mode, including training or reentry, and on any transaction and non-transaction screens, if the application is left unattended for more than 15 minutes, the application times out. The user returning to the application will be taken back to the login screen and will have to log in again. The transaction that the user was executing is cancelled and the user will have to re-execute the transaction.
The Oracle Retail Mobile Point-of-Service device times out of the application in 15 minutes when left unattended. Its session on the server also times out.
On a register, Oracle Retail Point-of-Service does not display the close, minimize, and maximize buttons. The application also implements Always-On-Top which means that any other application or screen cannot be used and brought to the forefront when the Oracle Retail Point-of-Service application is being used.
Oracle Retail Point-of-Service displays item images on the screen. The item images can be displayed from images that have been uploaded or are accessed from a URL. Care must be taken that the URL location of any of the images does not point to malicious locations where files can be downloaded and executed.
Live Personal Account Numbers (PAN) are not used for testing. The retailer must not use any live PAN numbers for implementation, development, or testing.
The following web sites publish these numbers as test PAN numbers:
https://www.paypal.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm
http://www.infomerchant.net/creditcardprocessing/credit_card_test_numbers.html
In addition, Oracle provides internal guidelines for creating sample data, which includes credit card numbers that are suitable for testing.
The Release 14.1 Oracle Retail POS Suite applications do not contain any default accounts, user IDs, or passwords. An application account ID and password are entered by the user during the installation process.
The Release 14.1 Oracle Retail POS Suite applications use a number of security tools to scan for security issues. This includes tools such as WebInspect and an internal fuzzing tool to test SQL security.
Retailers and system integrators who are customizing or extending any of the applications should consider running the following or similar tools on their customizations and extensions. As with any tool, the output of these tools should be analyzed in detail since the output may contain false positive warnings.
|
Note: You can use any tools that you choose. No recommendation of the following tools is intended or implied. |
The following sections list security tools and where each tool can be found. The tools fall into one of two categories:
Code scanning tools which work on the source code itself:
Intrusion testing tools which probe the operating system, web server, and application for vulnerabilities:
Klocwork Developer for Java is a commercial static code analysis tool. It provides automated detection of security vulnerabilities and quality defects. It integrates with Eclipse IDE. The security vulnerabilities include array index out of range, cross site scripting, null pointer exception, SQL injection, and unvalidated inputs.
Klocwork is found at the following web site:
FindBugs looks for bugs in Java programs. It uses static code analysis to inspect Java bytecode for occurrences of bug patterns. Static code analysis means that FindBugs can find bugs by simply inspecting program code. Executing the program is not necessary. FindBugs works by analyzing Java bytecode (compiled class files), so the program source code is not needed. Because its analysis is sometimes imprecise, FindBugs can report false warnings, which are warnings that do not indicate real errors. In Release 14.1, this tool was used to find bugs categorized as "Security".
FindBugs is found at the following web site:
HP Fortify is a tool that analyzes software for vulnerabilities. The static analysis component examines an application's source code for potentially exploitable vulnerabilities. The dynamic analysis component identifies vulnerabilities that can be found only when an application is running. All vulnerabilities can be ranked according to their PCI relevance.
HP Fortify is found at the following web site:
Nessus is a tool that automates the testing and discovery of known security problems. This is done through plug-ins. These plug-ins are very much like virus signatures in a common virus scanner application. Each plug-in is written to test for a specific vulnerability. These try to exploit the vulnerabilities or test for known vulnerable software versions. The tool also includes port scanning to look for open ports that could be exploited. It is essentially responsible for verifying that the operating system and any deployed middleware is secured. It is one of the first tools used in the secure environment to verify the security of the servers.
Nessus is found at the following web site:
Nikto is an open source web server scanner. It is designed to find various default and insecure files, configurations, and programs on any type of web server. Nikto is PERL software designed to find many types of web server problems, including server and software configuration problems, default files and programs, insecure files and programs, and outdated servers and programs.
Nikto is found at the following web site:
Wikto is primarily a web sever testing tool. It is very similar to Nikto but includes a Windows GUI interface. It also includes other features like the ability to spider a web site.
Wikto is found at the following web site:
Paros looks for security holes in web applications. It is an HTTP/HTTPS proxy for assessing web application vulnerability. It supports editing and viewing HTTP messages on the fly.
All HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified. The Spider feature is used to crawl the web sites and gather URL links. The Scanner feature is used to scan the server. The checks include checking for obsolete files and default files on the web servers as these could be exploited. It also tries to perform injection attacks by modifying data in the request parameters during scanning.
Paros is found at the following web site:
Wireshark is a network protocol analyzer that runs on most computing platforms including Windows and Linux. It can analyze several protocols. It is freely available as open source. It can capture live data from the network.
Wireshark is found at the following web site:
Tamper Data is a Mozilla Firefox add-on used to view and modify HTTP and HTTPS headers and post parameters. It can be used to security test web applications by modifying POST parameters.
Tamper Data is found at the following web site:
The Open Web Application Security Project (OWASP) periodically lists its top 10 vulnerabilities for web applications. You should pay special attention to these vulnerabilities when coding or testing modifications to the POS Suite applications. The OWASP Top Ten is found at the following web site:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
The Release 14.1 Oracle Retail POS Suite applications are tested with automated tools to help detect code vulnerabilities. FindBugs is one such tool that can help discover SQL injection vulnerabilities.
The following are two possible SQL injection vulnerabilities:
A PreparedStatement object is created based on a non-constant string of SQL. This may or may not include user-modifiable parameters from the web layer. If no parameters are included in the SQL, then no SQL injection vulnerability exists for that query.
A non-constant string of SQL is passed directly to an execute method of a Statement object. This may or may not include any user-modifiable parameters.
The safe and preferred way to execute SQL is to create a PreparedStatement object, apply the parameters, and call the execute method on that object. A PreparedStatement object has the SQL statement inside it compiled before any parameters are applied. Doing so means that a malicious parameter cannot change the SQL query that will be run.
Injection flaws are not limited to SQL injection. The POS Suite applications validate and escape dynamic data to prevent HTML, XML, and other types of injection.
Insecure storage refers to cryptographic storage and the management of encryption keys. Key management and the encryption and decryption of information are the responsibility of an external key management and encryption service.
For information on insecure communication, see the following web site:
http://www.owasp.org/index.php/Top_10_2007-A9
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption (usually SSL) must be used for all authenticated connections, especially Internet-accessible web pages, and backend connections as well. Otherwise, the application will expose an authentication or session token. In addition, encryption should be used whenever sensitive data, such as credit card or health information is transmitted. Applications that fall back or can be forced out of an encrypting mode can be abused by attackers.
Oracle Retail POS Suite applications are not designed to run over the public Internet, but are expected to run within a private network. Even still, all communication between a browser and either application is transmitted over SSL by default.
Oracle Retail POS Suite applications provide error messages to the user that convey the nature of the error without compromising important system information. Systems integrators and retailers who extend or modify the product should ensure that any new error conditions created by the modifications do not provide more information than necessary.
Oracle Retail Back Office and Central Office prevent cross-site scripting attacks through the proper use of JSP tags and output escaping of dynamic data. Because these two applications are built using the Struts framework, they make use of the <bean:write> tags provided by the framework for this purpose. Data is also validated during input using known good validation techniques.
Insecure object references occur when an application exposes key data directly or indirectly to the user. This could be in the form of a primary key value in a hidden field or shown in a URL. A malicious user could modify that data in an attempt to access objects that the user would not normally be able to access. Oracle Retail Back Office and Central Office both consider the current user's access prior to allowing the user access to objects.
Failure to control URL access could allow a user with insufficient permissions to perform an operation that the user would otherwise be unable to accomplish, if the user knew the URL to call and the data to pass to the application for that operation. Oracle Retail POS Suite applications prevent users from accessing URLs that they do not have permission to view.
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the attacker's behalf, such as changing the victim's e-mail address, home address, or password, or making a purchase.
Struts supports creating dynamic tokens using the TokenProcessor class. This is used in Oracle Retail POS Suite applications to prevent CSRF vulnerability. The saveToken method in TokenProcessor is used to generate a random token and insert the token into the current session. It is also included as a hidden parameter in the request. The isTokenValid() method in TokenProcessor is used to validate the token. It checks for a session token and compares it to the token obtained from the request parameter.
Securing the application environment and configuration covers the following areas:
Once sensitive data is stored in a database, that data must be protected from unauthorized access. Oracle Retail provides the following recommendations on how to protect that data:
Access to the stored procedures used in the data purge scripts should be restricted.
Authentication to the database should be done with a different user ID than authentication to the applications.
The Release 14.1 Oracle Retail POS Suite applications do not populate the database with any pre-defined users. An administrative user is created during installation.
The Oracle Retail POS Suite applications are configured through the use of parameters and system configurations. Some of the parameters and system configurations can affect compliance with PCI-DSS requirements.
By default, all parameters and system configurations are set to values that are compliant. If any of these are changed, be aware that this could affect the PCI-DSS compliance of the retailer and therefore not provide adequate security for the retailer's customers.
One example is the Timeout Inactive with Transaction parameter. The requirement states that the application time out in no more than 15 minutes. By default, this parameter is set to 15 minutes.
The parameter and system configuration descriptions in the Oracle Retail POS Suite Configuration Guide include a Security Sensitive attribute. This attribute documents whether changing the parameter or system configuration can impact compliance with the PA-DSS requirements.
If you access the POS Suite applications remotely, you must use two-factor authentication for remote access. Two-factor authentication requires that two of the three following authentication methods be used for authentication. Using one factor twice is not considered two-factor authentication. The authentication methods or factors are:
Something you know, such as a password or passphrase
Something you have, such as a token device or smart card
Something you are, such as a biometric
When performing two-factor authentication, it should not be possible to determine which factor failed authentication.
You can use the product of your choice for remote access, provided it offers security for your always-on connections. If you use a modem, it must be turned on only when needed, and turned off otherwise.
Oracle Retail recommends the use of strong cryptography, using technologies such as such as SSH, VPN, or SSL/TLS for encryption of non-console administrative access, such as web-based management. Open Source products like OpenSSL and OpenSSH are also available for encrypted administrative access.
|
Caution: A tool such as PUTTY also facilitates communication over rlogin and telnet. These protocols are not secure and should not be used in a secure environment. |
This section covers securing the applications using encryption and hashing.
The Release 14.1 Oracle Retail POS Suite applications are designed to be easily integrated with an external key management service selected by the retailer. The applications perform no encryption, decryption, or key management. Many enterprise applications are available to perform those functions. Because of this, the applications require integration with a key management service in order to start properly.
The applications are designed to plug into a key management service with the addition of a thin layer that wraps the interface to a key manager of your choice, such as RSA and so on. The adaptor can be instantiated by an application framework such as Spring, so that it is easy to write and deploy an adaptor for a different key manager without modifying application code. The Release 14.1 Oracle Retail POS Suite applications provide an adapter for the RSA Data Protection Manager Java Client. See the following file:
oracle.retail.stores.rsakeystore.rsainterface.RSAKeyStoreEncryptionService.java
This does not create a dependency on the RSA product, as a similar adapter could be developed for a different key management product. However, Oracle Retail Point-of-Service is a Secured by RSA Certified Partner Solution, certified with RSA Data Protection Manager, as documented on the following web site:
https://gallery.emc.com/community/marketplace/rsa?view=overview
|
Caution: The simulated key management package bundled with the Release 14.1 Oracle Retail applications may not be compliant with PCI-DSS. It is made available as a convenience for Oracle Retail consultants, integrators, and customers. If you use the simulated key manager, you may not be PCI-DSS compliant.The simulated key manager is an option that is chosen at the time of product installation. It is not installed by default. The simulated key manager must be replaced with a PCI-DSS compliant key manager for production use. |
|
Note to Retailers, Resellers, and Integrators: Store keys securely in the fewest possible locations and forms. Restrict access to keys to the fewest number of custodians necessary. |
The Oracle Retail encryption API consists of two methods-encrypt() and decrypt(). These methods are called within the Release 14.1 Oracle Retail POS Suite applications whenever encryption services are needed.
|
Note: The wrapper class, developed by an integrator or consultant, should map the Oracle Retail encryption API to the key management API. |
For more information about the Oracle Retail encryption API and how the wrapper class fits between the Oracle Retail POS Suite applications and the key management service, see the "Encryption Service Interfaces for Oracle Retail POS Suite Applications" in Chapter 3.
In order for another application to access sensitive data produced by Oracle Retail Point-Of-Service, access to the enterprise key management service is required. For example, when Point-Of-Service creates a POSLog, which is an XML stream that represents transactional data, a user of the POSLog would need to be able to decrypt the sensitive data it contains.
The Release 14.1 Oracle Retail POS Suite applications provide the ability to encrypt data by plugging in a third-party key management infrastructure such as RSA Data Protection Manager. Whichever key manager you use, you must ensure that the third-party key management infrastructure securely manages and deletes keys.
Oracle Retail Point-of-Service can request a transaction lookup based on a credit card number. The request message format does not include the card number, but only the token. This is sufficient for the lookup and does not expose sensitive data anywhere in the request message.
Oracle Retail Point-of-Service also creates a POSLog message, which is an industry standard format for representing a transaction. This message contains sensitive information, but it is never shown in clear text.
In order for an application to use sensitive data that is encrypted in the POSLog message, that application needs access to an encryption service provider in order to decrypt the data. Many enterprise key managers are available on the market, and it is expected that a retailer would have an implementation in order to protect sensitive data. The Release 14.1 Oracle Retail POS Suite applications require integration with an encryption service. They will not start properly without an encryption service.
Encryption and decryption are not performed directly by Oracle Retail POS Suite. These actions are performed by an integrated encryption service. The encryption service should not be hosted on the same physical server that hosts the Release 14.1 Oracle Retail POS Suite applications. The encryption key store should not be the same database that hosts the Oracle Retail POS Suite application data.
You must ensure that the communication with the authorizer is secure. Sensitive data traveling across the network between the store and the authorizer should be encrypted with SSL technology.
Oracle Retail Point-of-Service contains a pluggable interface for authorization engines. It does not log sensitive data during the course of an authorization request. If Oracle Retail Point-of-Service is modified, ensure that it is not changed to log authorization request data or response data in clear text, as this data could include sensitive data. Be aware that under certain conditions, an authorization request may be serialized or queued onto local storage. Ensure that sensitive data is not written in clear text to local storage when an authorization request is queued.
In addition to rendering sensitive data unreadable anywhere it is stored, that data is rendered unreadable even while stored in system memory. The data is encrypted immediately as it is read and released as soon as functionally possible.
In-memory encryption is accomplished through the use of the Java class, EncipheredData. It is used to maintain sensitive data in encrypted and masked formats and should be instantiated and populated immediately upon reading sensitive data into memory. For a diagram that describes the class, see Figure 1-5.
Because the Receipt Builder editor needs a serialized file of the transactions in question in order to help design the blueprint, there is a configurable option of whether to enable or disable this serialization. Transactions with sensitive data that are serialized (using default Java object serialization) will have sensitive data in the file. However, the sensitive data is contained in the EncipheredData object previously described; therefore it is present only in encrypted and masked format. It is not stored in clear text. Nevertheless, it is wise to disable the persist option in a production environment. This setting is found in the file, BlueprintedDocumentManager.xml. The property name is persistBeansAsDataObject and is set to false by default.
|
Note to Linux Users: Due to the file at /proc/kcore, Oracle Retail advises you to implement a secure kernel solution using a tool such as the tool at the following web site:http://www.GRSecurity.com. |
The Oracle Retail POS Suite applications prompt for a user ID and password for access. The password is hashed with salt, multiple times, and the ID and resulting hash values are compared with known users in the database. The hashing algorithm is configurable, but the default algorithm is SHA-256.
This section describes the following technical areas:
A Key Store client is required at each deployment point. This enables access from the server-based application as well as the client application when the Key Store server is offline. Figure 1-2 illustrates the design.
The components of the deployment model are described in the following table.
| Component | Description |
|---|---|
| Corporate | Centralized, corporate deployment environment |
| Store-x | Local store deployment environment |
| Central Office, Returns Management, Back Office, POS Server, POS Client-x | Oracle Retail Stores applications |
| Key Store Server | Centralized encryption key repository |
| Key Store Client | Local client APIs for Key Store access as well as local key cache for offline support |
The primary API is the KeyStoreEncryptionServiceIfc. This interface abstracts away the specifics of each vendor Key Store API.
Extensions to the base web application classes are made to ease access to this service.
The application-facing interface is simplified because a complex cipher is being returned by the API. The cipher text not only includes the encrypted data, but also contains metadata about the key that was used to encrypt the data. There is no need to separately store the key identifier or be concerned about which key was used with which data object. Figure 1-5 shows an example of this structure.
|
Note: Any database column used to store cipher text must be expanded to support the additional data. |
There are two similar interaction patterns for accessing the new encryption service, J2EE Session Bean and POS POJO.
To access the encryption service from within a stateless session bean, follow the pattern shown in Figure 1-6.
The following steps describe the process shown in Figure 1-6.
The session bean asks its base class (EnterpriseBeanAdapter) for the service implementation.
The base class calls out to Spring using the BeanLocator class to get a handle to the EncryptionService implementation class.
Once returned, the session bean calls the class, using its interface, to handle any encryption needs.
As shown in Figure 1-7, a similar pattern is followed to handle encryption needs from within an action.
The following steps describe the process shown in Figure 1-7.
The action asks its base class (Action, DispatchAction, DispatchLookupAction) for the service implementation.
The base class calls out to Spring using the BeanLocator class to get a handle to the EncryptionService implementation class.
Once returned, the action calls the class, using its interface, to handle any encryption needs.
As shown in Figure 1-8, the pattern is slightly different for Oracle Retail Point-of-Service. The Manager/Technician framework is used to access the encryption service.
The following steps describe the process shown in Figure 1-8.
Any site needing access to encryption services uses the Dispatcher to get a handle to the EncryptionManager.
That manager delegates to the configured EncryptionTechnician using a valet.
The EncryptionTechnician uses Spring (using the BeanLocator) to access the configured EncryptionService and calls the class, using its interface, to handle any encryption needs.
