Get documents about "Type Your Title Here - Download Now DOC
Shared by: HC120808061811
-
Stats
- views:
- 4
- posted:
- 8/7/2012
- language:
- Latin
- pages:
- 14
Document Sample
Building Secure J2EE Applications
BUILDING SECURE J2EE APPLICATIONS USING ORACLE
Cary Bakker, Oracle Corporation
John Gammon, Oracle Corporation
Adam Leftik, Oracle Corporation
INTRODUCTION
This paper grew out of an interesting problem that exists within the defense community. There is a new strategy for
exploiting information technology to assist the fighter. This strategy, broadly speaking, is based on a concept know
as “network-centric” warfare. The idea is for the war planner to have access to all the tactical information from
units operating in a theater without compromising any particular unit. Essentially each unit is a node on the defense
network both as a producer and consumer of intelligence. Of course, not all units, can, or should, have knowledge
of the specific missions of any particular unit without having a “need to know.” Additionally, the inclusion of
various coalition elements in the operational planning environment adds another security dimension to the design
problem. Every single user in the operations center has varying levels of security clearance. The mission data itself
is time-sensitive so that after a specific period, access to the mission detail might be declassified so that other units
operating in the same airspace could recognize friend from foe. Finally, speed of configuration and maintenance of
the operations center data-flow environment were too slow to meet the war planner’s needs. Given these issues, the
chief design goals were to simplify the configuration and maintenance resources in connection with operational
planning, to provide access to information on a “need to know” basis and to prevent any unauthorized access to
information by someone using things like IP spoofing or “man-in-the-middle” attacks. It is clear that using some
form of network or data segregation was going to be an ineffective approach.
No single tool provides adequate protection, especially when designing a system that is predicated on a high degree of
flexibility along with a maximum amount of security control. The Oracle platform has a range of tools well-suited
to particular security/data problems. The challenge was to combine these tools in such a way as to meet the specific
design goals of the defense project. It became clear that only a layered approach to security would resolve the
competing needs of the defense community. This paper attempts to provide a summary of the key issues anyone
designing an application should have in mind. It also takes the application developer from the high-level
architecture to the specific implementation of security within each of the application layers. The goal is to provide
the application developer with a means of understanding how to use the available security tools in the most effective
manner.
SECURITY CONCEPTS
AUTHENTICATION
There are two parties, in the simplest sense, to an electronic exchange. The process of “authentication” is the act of
proving to the corresponding party that you are who you claim to be and vice versa. In order to accomplish this,
each party to a transaction should be able to guarantee who they are to the other party. In addition, each party must
be the source of its respective transmitted data no matter what subsequent activities occur.
As mentioned above, identification is one element of authentication, and it can occur in two places: locally on the
client machine or remotely. The difference between these two is that local identification occurs with the interaction
Paper #
Building Secure J2EE Applications
of the user whereas remote identification does not necessarily involve the user. It is actually less secure to involve
the user in a remote identification because of the possibility of transmission interception. Given these conditions,
what methods are available to prove “identity”? Overall, there appears to be just three general means: holding some
special device, a unique piece of knowledge, or some special physical characteristic. These methods of identification
can be used individually or in combination to achieve the resulting confidence that identity is known.
The other piece of authentication is verifying the party as the source of the data. This is extremely important
because transactions require that neither party can invalidate the transaction after the fact by repudiating its
occurrence. When the discussion turns to the use of Public Key Infrastructure (PKI), this element of non-
repudiation for transactional integrity will become clear.
AUTHORIZATION
Authorization is the process of associating an authenticated identity with a set of privileges. Authorization gets
trickier when one considers the possibility of privilege delegation. Even though the process of authorization is not
integral to authentication, what privileges are assigned and/or delegated has a tremendous impact on the value of the
system and the integrity of the security chain.
CONFIDENTIALITY
This simply means that there is no unauthorized access to private data. Data that is persistent (resides in a database
or some permanent datastore) or data that is transmitted is not accessible by unauthorized individuals. The level of
control one can exercise over the given data is directly related to the underlying degree of confidentiality one can
deliver across a system. This is intimately related to authentication and authorization.
INTEGRITY
Data integrity means that the persistent or transmitted data has not been altered in any fashion from its original form.
This is related to the concept of non-repudiation.
INDUSTRY STANDARD SECURITY TOOLBOX
There are two key tools that have developed over the last decade that are considered industry standard approaches to
addressing the security needs of the electronic organization. They are “industry-standard” because they are not
proprietary in the sense of being only available to clients of a particular business.
PUBLIC KEY INFRASTRUCTURE
Public key infrastructure addresses the following areas directly: remote authentication and data integrity. It supports
the area of authorization but does not actually provide the implementation for authorization and its use assists in the
area of providing data confidentiality. What this implies, of course, is that there is an infrastructure that uses public-
key techniques to address these broad areas of security.
What is a public-key technique? This falls into the area of cryptography. Although any detailed discussion of
cryptography is outside the scope of this discussion, a simple understanding of the development of cryptography is
necessary. Prior cryptographic history relied on symmetric keys to encrypt and decrypt messages. What this meant is
that both parties to a transmission had to have the same key or cipher to send or receive a message. One can easily
see the problems involved with this approach. The most important issue with this approach is how can keys be
managed to prevent unauthorized agents from obtaining them? In short, the answer was not easily. Additionally, a
separate key will be needed for each pair of users who would like to communicate, making symmetric keys impossible
to use as the number of keys required by a large group would quickly become unmanageable. In the last 30 years,
researchers have shown that it is possible to encrypt and decrypt messages without both parties holding the same key.
A sender can actually encrypt and decrypt messages securely by using a combination of keys: one, a private key that is
never shared; two, a public key that is available to the public. This is known as asymmetric key management. Here is how
this works:
With asymmetric keys, each party has both a public key and a private key. The public key is given to everyone, while
the private key is not shared – it is kept secret by its owner. With any public and private key pair, messages that are
Paper #
Building Secure J2EE Applications
encrypted with the public key can be decrypted with the private key, and vice-versa. It’s easy to see that anyone can
use someone else’s public key to encrypt a message that only the owner of the corresponding private key can decrypt.
The owner of the key set can also encrypt a message with his/her private key to send it to a recipient, and anyone can
decrypt the message using the corresponding public key. However, they will be assured that the owner of the private
key created the message. When two users communicate, they will each have their own private/public key pairs.
Sender A will encrypt a message with Sender B’s public key, and subsequently sign the message with his/her (Sender
A’s) private key. Sender B can use Sender A’s public key to verify the signature, thereby proving the message could
only have been created by Sender A. And Sender B is the only person that can decrypt the message with the
required private key. This description is vastly simplified, but it at least gives one a feel for how public key
cryptography functions.
The mathematics behind the public key / private key pair is beyond the scope of this paper. However, the theory is
that it is easy for a user to generate public / private key pairs, but immensely difficult for anyone to calculate what the
private keys are based on the encrypted messages and the public keys. The mathematics of the cipher rely on the
use of prime numbers in the sense that the public key represents the product of a sequence of prime numbers. The
private key holds the actual sequence. Anyone wishing to discover that sequence by brute-force trial and error has
an increasingly time-consuming and ultimately unprofitable experience if the length of the product is sufficiently large.
This is a very simplistic description, but it nevertheless provides a simple theoretical construct to understand and
thereby have confidence in the technique.
DIGITAL CERTIFICATES
There are many types of digital certificates. For the purpose of this discussion, the digital certificate reviewed is the
X.509 public-key certificate (version 3). The format of the X.509 digital certificate is as follows:
1 2 3 4 5 6 7 8 9 10 11
Version Serial Signature Issuer Validity Subject Subject Issuer Subject extensions Digital
Number public unique unique signature
key info id id
A certification authority is responsible for authorizing elements 1 through 10 of the above table. The definition of
the important elements follows:
Signature – the algorithm identifier of the algorithm used to calculate the signature plus any parameters.
For example, SHA-1 with RS
Issuer – the distinguished name of the issuer of the certificate;
Validity – the period of time the certificate is considered valid;
Subject – the distinguished name of the owner of the certificate;
Subject public key info – the public key of the subject;
Issuing a certificate is the act of binding a subject name with a public key in accordance with a certificate policy.
There are other considerations in adopting this environment for security which we can only mention: certificates
require some repository or storage medium, certificates require some process for revocation, provision has to be
made for lost and expired keys, key history should be maintained, and time-stamping of activities is important.
Digital Certificates essentially provide three key features:
1. A means of establishing trust
2. A unique naming mechanism
3. A means of disseminating the validity of a binding between a name and a key
In short, Digital Certificates simply establish the name of something, but that is an important step.
Paper #
Building Secure J2EE Applications
SECURE SOCKET LAYER PROTOCOL
The Secure Socket Layer (SSL) is essentially a means of providing communications security between two devices. It
has 3 primary goals: cryptographic security, interoperability and extensibility. Cryptographic security can be
accomplished in a number of ways. In our scenario, we are using the public key encryption approach previously
described. As a protocol, it simply defines what activities occur, not necessarily how these are implemented. The
SSL protocol resides within the network layer of the Open System Interconnection (OSI) stack on top of TCP/IP
but below application layer services such as HTTP. Given its place within the OSI model, it is application protocol
independent making it highly interoperable since higher level application protocols can sit on top of SSL.
SSL contains numerous sub-protocols. The process defined in SSL is as follows: messages designated for
transmission are broken up into manageable portions, even compressed if desired. Next, a Message Authentication
Code (MAC) is applied with the resulting message encrypted and transmitted to a receiver. On the receiving end,
the message is decrypted, verified, decompressed (if necessary), reassembled and forwarded to application layer
services.
To understand the SSL protocol, one has to be aware of its key element: the handshake protocol.
SSL HANDSHAKE PROTOCOL
The handshake begins with client and server hello messages. These messages establish the protocol version, session
ID, cipher suite, and compression method. Following the establishment of these parameters, two random messages
are generated and exchanged. Subsequently, certificates are exchanged and processed as follows:
1. Check that the certificate has not expired
2. Check that the certification authority is in the “trusted” list
3. Validate the message issuer’s signature with the issuing certification authority’s public key
4. [Optional] Check that the domain name of the server’s certificate matches the domain name of the server
itself
5. Use the private key to decrypt and a pre-master secret
In our scenario, we are using mutual-authentication where the both the client and the server use digital certificates to
authenticate each other (the validation steps listed above are performed by both the client and the server). A
negative outcome from any of the steps will invalidate the handshake and prevent a successful connection.
Moreover, a fatal alert will terminate the connection in the event of a tampered message. Given PKI, Digital
Certificates, and SSL, one will see how to create a multi-level, secure framework implementation that application
developers can use to deliver technology services to the business.
SERVICE ORIENTED AND WEB SOFTWARE ARCHITECTURES
A SECURE SOFTWARE ARCHITECTURE
MULTI-LAYERED SECURITY FROM THE GROUND UP
Architecting secure solutions requires designing security from the ground-up on day one. Too often security is an
after thought. Furthermore, applications all too often tend to rely on network hardware to prevent intrusions and
unauthorized access to applications. Secure solutions require many layers of authentication and authorization in
order to ensure confidentiality and data integrity. As multi-tier environments are commonplace amongst J2EE
based applications, and due to the proliferation of web and service-oriented architectures, securing access is
paramount. This is a sample architecture designed to support J2EE-based architectures with strict security
requirements. It leverages the Oracle Platform in order to ensure scalable, performant, and secure solutions.
While the use of network firewalls and other external hardware or software solutions is important, building a secure
software system is one’s first priority.
Paper #
Building Secure J2EE Applications
SECURING THE WEB TIER USING STRONG AUTHENTICATION AND SECURE TRANSMISSION
SSL MUTUAL AUTHENTICATION CONFIGURATION WITH ORACLE HTTP SERVER – MOD OSSL
The Oracle HTTP Server (OHS) has built in support for SSLv3.0, including SSL-Mutual Authentication. OHS
uses a module called Oracle SSL (Mod OSSL) in order to provide SSL services for the Web Server and Web Clients.
Mod OSSL can provide confidentiality, authentication, and data integrity services between OHS and Web Clients.
Because SSL sits on top of the network layer, secure communication can be established for the HTTP protocol via
bi-directional trusts are between Web Clients and OHS nodes. The use of bi-directional trust is not limited to web
browsers, but can also be employed by Web Service clients as well. Here is a sample configuration (in OHS’s
httpd.conf configuration file) to support SSL Mutual Authentication using Mod OSSL and OHS (windows version):
# load mod_ossl
LoadModule ossl_module modules/ApacheModuleOSSL.DLL
<IfModule mod_ossl.c>
# Some MIME-types for downloading Certificates and CRLs
#
Paper #
Building Secure J2EE Applications
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First either `none'
# or `dbm:/path/to/file' for the mechanism to use and
# second the expiring timeout (in seconds).
SSLSessionCache shmcb:logs\ssl_scache(512000)
# This directive sets the timeout in seconds for the information stored
# in the global/inter-process SSL Session Cache. It can be set as low as
# 15 for testing, but should be set to higher values like 300 in real life.
SSLSessionCacheTimeout 300
# Semaphore:
# Configure the path to the mutual explusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex sem
# Logging:
# The home of the dedicated SSL protocol logfile. Errors are
# additionally duplicated in the general error log file. Put
# this somewhere where it cannot be used for symlink attacks on
# a real server (i.e. somewhere where only root can write).
# Log levels are (ascending order: higher ones include lower ones):
# none, error, warn, info, trace, debug.
SSLLog logs\ssl_engine_log
SSLLogLevel warn
## SSL Virtual Host Context
# NOTE: this value should match the SSL Listen directive set previously in this file
# otherwise your virtual host will not respond to SSL requests.
#
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot C:\9ias\Apache\Apache\htdocs
ServerName sweetdeal.sbcglobal.net
ServerAdmin you@your.address
ErrorLog logs/error_log
TransferLog "logs/access_log"
Port 443
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# List the ciphers that the client is permitted to negotiate.
SSLCipherSuite
SSL_RSA_WITH_RC4_128_MD5:SSL_RSA_WITH_RC4_128_SHA:SSL_RSA_WITH_3DES_EDE_CBC_SHA:SSL_
RSA_WITH_DES_CBC_SHA:SSL_RSA_EXPORT_WITH_RC4_40_MD5:SSL_RSA_EXPORT_WITH_DES40_CBC_SH
A
# Server Wallet:
# The server wallet contains the server's certificate, private key
# and trusted certificates. Set SSLWallet at the wallet directory
# using the syntax: file:<path-to-wallet-directory>
SSLWallet file:<path-to-wallet-directory>
# Server Wallet Password:
# Both clear text wallet password and obfuscated password are allowed
# here. An obfuscated one is recommended.
SSLWalletPassword <wallet-password >
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
Paper #
Building Secure J2EE Applications
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath conf\ssl.crl
#SSLCARevocationFile conf\ssl.crl\ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional and require
SSLVerifyClient require
# SSL Engine Options:
SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars
</Files>
<Directory cgi-bin>
SSLOptions +StdEnvVars
</Directory>
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
# Per-Server Logging:
CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\"
%b"
</VirtualHost>
## SSL Support#### When we also provide SSL we have to listen to the## standard
HTTP port
Listen 443
</IfModule>
SECURING THE MIDDLE-TIER
MOD OC4J
In a typical J2EE configuration, OHS uses another module, Mod OC4J, to proxy requests intended for J2EE
applications. Mod OC4J looks at the incoming HTTP requests and determines if it should proxy them to Oracle
Containers for J2EE (OC4J) via the Apache Java Protocol (AJP). Mod OC4J is also used to determine which
container should accept the request in load-balanced and clustered environments. In secure environments, Mod
OC4J can also be instructed to extract client-side SSL certificates and provide the certificate to the OC4J container
for programmatic access. This allows J2EE based applications to access the same credentials that were used to
authenticate the Web Client via OHS. Here is a sample configuration (in OHS’s mod_oc4j.conf configuration file)
that extracts SSL variables and passes the request to the OC4J container if the URL ends with /myapp or /myapp/*:
<IfModule mod_oc4j.c>
# propagate credentials to OC4J
Oc4jExtractSSL on
<Location /oc4j-service>
SetHandler oc4j-service-handler
Order deny,allow
Deny from all
Allow from localhost
</Location>
</IfModule>
Oc4jMount /myapp home
Oc4jMount /myapp/* home
</IfModule>
Paper #
Building Secure J2EE Applications
One caveat is that Oracle 9ias version 9.0.3 does not provide SSL communication over AJP between Mod OC4J and
OC4J. However, AJP with SSL will be available in the 9.0.4 release.
SECURITY FILTERS
When an incoming request is authenticated via SSL Mutual Authentication the incoming request will expose the
digital certificate via the javax.servlet Application Programming Interface (API) and the java.security API --consistent
with the Java Servlet 2.3 specification. For example, here is a java servlet code snippet:
//Servlet service method….
ServletRequest request = null;
…
java.security.cert.X509Certificate [] certs =
request.getAttribute(java.security.cert.X509Certificate.getClass().getName());
…
Now that the certificate’s information is available programmatically, a simple Servlet Filter can be written that
prevents access to OC4J without proper credentials. The Servlet Filter can look in the ServletRequest for the
certificate and verify the certificate was issued by a known and trusted Certificate Authority. If the request contains
the proper credentials, it will allow the request to continue down the filter chain. However, if the proper credentials
are absent from the request, the Servlet Filter can respond by issuing a 403 forbidden error to the client and stop the
processing of the request immediately.
Paper #
Building Secure J2EE Applications
SECURING THE DATABASE
When designing secure enterprise applications, architects should also leverage the security features of the database
server. Using a multi-layered security architecture provides additional safeguards to protect sensitive data.
Application designs must make use of database connection pools to provide performant and scalable solutions. In
doing so, typical n-tier architectures utilize “One Big Application User” in order to pool the database connections.
As connections are recycled between application users in the middle-tier, the database only authenticates “One Big
Application User”. Relying simply on middle-tier authentication to mediate access to the database is insufficient in
highly secure environments. Therefore, it is critical that the application users also be database users.
Paper #
Building Secure J2EE Applications
JDBC OCI CONNECTION POOLS AND PROXY AUTHENTICATION
When application users are also database users, all the security and auditing features of the database are available. In
order to utilize connection pools and authenticate application users with the database, Oracle 9i offers proxy
authentication. Proxy authentication allows a user to be authenticated by the database and create a ‘light-weight’
session with minimal database privileges, e.g. connect and proxy users. When an application user interacts with the
database via the middle-tier, the application user is proxy authenticated via the proxy user and a complete ‘heavy’
database session is created. The ‘heavy’ database session is associated with the application user and all the security
and auditing features are enforced for the database and application user.
SSL MUTUAL AUTHENTICATION
Proxy authentication technology can also make use of SSL authentication techniques. Oracle’s SSL Mutual
Authentication can be used to provide authentication, confidentiality, and data integrity.
Authenticating the proxy user via Mutual SSL Authentication ensures that that the proxy user and the proxied user
are trusted by the database. Additionally, the middle-tier authenticates and verifies its trust of the database server.
Proxied users can provide their certificates as credentials to the database server. In the following example, the
APP_SERVER database user is authenticated using the APP_SERVER’s digital certificate when acquiring an SSL
connection between the middle-tier and the database server. The proxied user, JOHN_ROHLER, is then proxy
authenticated though APP_SERVER. The database will use the Subject DN from the digital certificate for both the
proxy user and the proxied user. The authentication process will ensure that the Certificate Authority from which
the digital certificates were issued is trusted and valid. The key point here is that the APP_SERVER user has
Paper #
Building Secure J2EE Applications
minimal privileges (connect and proxy privilege for JOHN_ROHLER), while the JOHN_ROHLER user is granted
the application-level role.
Sample Script:
CREATE USER APP_SERVER IDENTIFIED GLOBALLY AS ‘CN=APP_SERVER, C=US’;
CREATE USER JOHN_ROHLER IDENTIFIED GLOBALLY AS 'CN=Jon Rohler, C=US';
GRANT "CONNECT" TO APP_SERVER;
ALTER USER JOHN_ROHLER GRANT CONNECT THROUGH APP_SERVER;
GRANT "CONNECT" TO APP_SERVER;
GRANT “APPLICATION_ROLE” TO JOHN_ROHLER;
SECURE APPLICATION ROLES
One of the common concerns with architectures that have application users that are also database users is that users
can connect to the database directly and bypass the middle tier. However, utilizing Oracle Secure Application Roles
application designers can secure against ‘outside applications’ from manipulating data and schema objects. For
example, JOHN_ROHLER should only have SELECT privileges to a table called ACCOUNTS if and only if he is
accessing the database through a trusted middle tier application. Secure Application Roles can require that database
roles only be granted through a PL/SQL package. The PL/SQL package can verify that JOHN_ROHLER is being
proxy authenticated by APP_SERVER (key point: via a trusted middle tier) before granting a role that gives the
JOHN_ROHLER user privileges to schema objects.
Sample Script:
CREATE OR REPLACE PACKAGE BODY MY_ROLE IS
PROCEDURE check_access
IS
proxy_usr VARCHAR2 (4000);
ip_address VARCHAR2 (16);
BEGIN
proxy_usr := SYS_CONTEXT('userenv','proxy_user');
ip_address := SYS_CONTEXT('userenv','ip_address');
IF proxy_usr = ‘APP_SERVER’ AND ip_address = ‘192.168.1.125’ THEN
DBMS_SESSION.SET_ROLE('MY_APPLICATION_ROLE');
END IF;
END;
END;
/
GRANT SELECT ON ACCOUNTS TO MY_APPPLICATION_ROLE;
GRANT EXECUTE ON MY_ROLE TO JOHN_ROHLER;
CREATE MY_APPLICATION_ROLE IDENTIFIED USING schema_owner_for_pl_sql_package.MY_ROLE;
GRANT "MY_APPLICATION_ROLE" TO JOHN_ROHLER;
ALTER USER JOHN_ROHLER DEFAULT ROLE ALL EXCEPT MY_APPLICATION_ROLE;
The role MY_APPLICATION_ROLE is identified using the fully qualified package name for MY_ROLE. When
the application requires that a given role be enabled, the application must call the PL/SQL package to enable the role.
In JDBC it would look something like this:
…
Connection con = null;
CallableStatement cs = null;
try {
Paper #
Building Secure J2EE Applications
con = getConnection(); //get a proxy connection from jdbc oci connection pool code
not shown
cs = con.prepareCall(“begin schema_owner.my_role.check_access(); end;”);
cs.execute();
/**
* now use con toissue a query against account table this will fail if this is
* not part of middle tier application…
*/
} catch (SQLException sqle) {
//handle the execption
} finally {
if (con != null) {
try {con.close();} catch (SQLException sqle){}
}
if (cs != null) {
try{con.close();}catch(SQLException sqle){}
}
}
Assuming the above code was executed via the middle tier from the correct middle tier IP address, the connection
(session) now has the MY_APPLICATION_ROLE enabled and can access the ACCOUNTS table via JDBC.
However, a permission error will occur if the user accesses the database via SQL PLUS, for instance, and types:
exec schema_owner.my_role.check_access();
SELECT * FROM ACCOUNTS;
This shows that Secure Application Roles can be used to control access to schema objects based on the way the user
is accessing the Oracle9i database.
ORACLE LABEL SECURITY
Most applications require both the coarse-grained authorization model that Oracle’s Secure Application Roles
provide, and a fine-grained authorization model for securing access to data rows. Oracle’s Label Security option
provides the required fine-grained row-level authorization services. Users have access to the database object but
each database table row is assigned an additional Label Security setting. Since the database session is associated with
the application user, and because that user has been associated with a Label Security setting, the information returned
to the user is only that set of data that falls within the user’s allowed visibility. A detailed description of Label
Security is outside our scope of this paper. However, a brief description is that Label Security is added to a database
table by adding a Label Security column to contain the Label Security information for each row. One way to
approach this is by creating policies through Policy Manager. Another possibility is by creating custom scripts that
perform the following functions:
1. Create the Policy
EXECUTE SA_SYSDBA.CREATE_POLICY(-
'MYPOLICY','MYCOLUMN','READ_CONTROL,WRITE_CONTROL,CHECK_CONTROL,LABEL_DE
FAULT,UPDATE_CONTROL');
2. Create the Policy Levels
(one thing to note here is you must assign higher numbers to levels which are more sensitive, and lower
numbers to levels which are less sensitive – see label security admin guide pg 47);
EXEC SA_COMPONENTS.CREATE_LEVEL('MYPOLICY',9000,'C','CLASSIFIED');
EXEC SA_COMPONENTS.CREATE_LEVEL('MYPOLICY',2000,'HS','HIGHLY_SENSITIVE');
EXEC SA_COMPONENTS.CREATE_LEVEL('MYPOLICY',1000,'S','SENSITIVE');
Paper #
Building Secure J2EE Applications
3. Create the Group Labels
EXEC SA_COMPONENTS.CREATE_GROUP('MYPOLICY',9000,'CG','CLASSIFIED GROUP');
EXEC SA_COMPONENTS.CREATE_GROUP('MYPOLICY',2000,'HSG','HIGH SENSITIVE GROUP');
EXEC SA_COMPONENTS.CREATE_GROUP('MYPOLICY',1000,'SG','SENSITIVE GROUP');
4. Set user labels to users
BEGIN
SA_USER_ADMIN.SET_USER_LABELS(POLICY_NAME=>'MYPOLICY',
USER_NAME => 'CLASSIFIED USER',
MAX_READ_LABEL => 'C::CG,HSG,SG',
MAX_WRITE_LABEL => 'C::CG',
MIN_WRITE_LABEL => 'C')
;
END;
/
BEGIN
SA_USER_ADMIN.SET_USER_LABELS(POLICY_NAME=>'MYPOLICY',
USER_NAME => 'HIGH SENSITIVE USER',
MAX_READ_LABEL => 'HS::HSG,SG',
MAX_WRITE_LABEL => 'HS::HSG',
MIN_WRITE_LABEL => 'HS')
;
END;
/
BEGIN
SA_USER_ADMIN.SET_USER_LABELS(POLICY_NAME=>'MYPOLICY',
USER_NAME => 'SENSITIVE USER',
MAX_READ_LABEL => 'S::SG',
MAX_WRITE_LABEL => 'S::SG',
MIN_WRITE_LABEL => 'S')
;
END;
5. Apply the Policy to the tables that one wants to add to label security
EXEC sa_policy_admin.apply_table_policy('MYPOLICY','SCHEMAOWNER','MYTABLE');
6. Update the tables with label value for each row
UPDATE SCHEMAOWNER.TABLE_NAME SET MYCOLUMNAME = char_to_label('MYPOLICY',
'C::CG')
WHERE MYUNIQUEKEY = 'SOMEUNIQUEVALUE';
Paper #
Building Secure J2EE Applications
Essentially what you end up with is this:
MY TABLE
Column 1 Column 2 LabelColumn When the Classified User connects to the
database, that user can see all 3 sample rows
A 100 9000 above. However, if the Sensitive User
connects, then that user will only see the table
B 200 2000 row with a value of “C” in column 1.
C 300 1000
CONCLUSION
Developing secure applications requires a multi-layered approach. What has been shown is a means of protecting
both the data and the path to the data, but his is by no means the only answer. For those who begin to architect n-
tier systems, this approach provides a solution to a situation where middle-tier applications have to be secured. It
can be applied not only to web-service applications, but to any application architecture as long as the application
layers can transmit an industry standard digital certificates for use with SSL. Although every situation will require its
own solution set, the point we have tried to demonstrate is that the tools available in the Oracle Platform can provide
the necessary flexibility, even in the most demanding environment.
Paper #
#
