Web services security in Java EE the present and the future

splattersquadSecurity

Nov 17, 2013 (3 years and 7 months ago)

78 views

Web services security in
Java EE



the present and the future

Introduction

In my earlier article “Moving to SOA in
J2EE

1.4” published in the February issue of JDJ
[1] I introduced you to the new object distribution model based on web services that has
bec
ome available to Enterprise Java applications with the advent of
Java EE
1.4. In this
article I look at the available security features in
Java EE

SOA.

T
he article presents you
a
hands
-
on knowledge about web services security in
Java
EE

that we acquired while adding security support to OptimalJ
1
-
generated SOA applications,
it is based on the
J2EE 1.4 specification
itself as well as on what is actually supported and
works in three major
J2EE

1.4 application servers


JBos
s 4.0.4, WebSphere 6.0.2.x,
and WebLogic 9.1.
You’ll learn about
new mandatory security features available to web
service endpoints in Java EE 5.0 [3]
.

Over
view of Security in
Java EE

Java EE

comes with a mature security model that provides for the following guaranteed
features that must be supported by all compliant application servers:
authentication
,
authorization
,
confidentiality
, and
integrity
.
Even though not yet required by the
specification, most high
-
end application servers also support some sort of
auditing

of
security
-
related events and

non
-
repudiation

(a means of preventing a
n invocation

sender
from denying responsibility

for the action
)
for communication with web service
components.

Authorization is based on logical security roles that are simple names defined by the
component provider or application assembler in XML deployment descriptors. All
Java
EE

components


JSPs, Servlets, and Ent
erprise JavaBeans allow access to their code to
be restricted declaratively based on logical security roles. In the case of EJBs, access can
be limited on an enterprise bean’s method level, whereas for JSPs and Servlets access is
enforced based on a JSP’s
or Servlet’s URL and the
utilized
HTTP method (e.g. POST,
GET, etc.)
. In addition to declarative authorization, programmatic authorization is also
supported, in which case a component’s code can dynamically inquire whether the
security co
ntext of the current user is associated with a particular logical security role and
make a decision based on this analysis. How a given principal is actually mapped to a set
of security roles depends on the
Java EE

notion of a
security domain

and the princ
ipal
authentication mechanisms associated with the domain.

The confidentiality and integrity requirements are met at the transport layer with the help
of the Secure Sockets Layer (SSL 3.0) protocol [4] and the related IETF standard
Transport Layer Security

(TLS 1.0) protocol [5]. For SSL and TLS only X.509
certificates [6] are supported for authenticating principals. Kerberos
-
based authentication
mechanisms in TLS [7] are presently regarded as optional and are not implemented by
the application servers this

article concentrates on.




1

OptimalJ (
www.optimalj.com
) is an MDA
-
based development product that enables to generate (from
us
er
-
defined models) complex, standards compliant J2EE 1.3 and J2EE 1.4 applications that run on JBoss,
WebSphere, and WebLogic.

The authentication security requirement is by far the most difficult to explain as it
requires

understanding
of
the
Java EE
notion of a security domain
, which
is essentially a
security mec
hanism used to authenticate the user. Here are
the
three arbitrary examples of
security domains:

1.

A security domain where users are authenticated based on their X509 certificates
presented during an SSL handshake. In this case the protocol used by the clien
t for
communication with the application server can be one of: HTTPS, IIOP/SSL, or
JRMP/SSL.

2.

A security domain that uses the SRP protocol [8] in communicating a user name and
password to the server in a secure fashion. For this security domain, the
communi
cations protocol that the client uses can be JRMP.

3.

A security domain that uses the HTTP Basic Authentication in communicating a user
name and password to the server. Such a security domain will use either HTTP or
HTTPS as the supported communications proto
col.

Different security domains entail different types of principals for representing users. In
the first security domain
presented above,
a principal will be derived from an X509
certificate or a certificate chain that the user presented du
ring an SSL handshake. In the
second example, a principal will be obtained from the user name specified by the client.
Here's

a code sample taken from JBoss

that shows

how a certificate chain can be mapped
to a principal:

public Principal toPrinicipal(X509Certificate[] certs)

{


Principal subject = certs[0].getSubjectDN();


return subject;

}

Thus a security domain deals with a set of principals of a particular kind (e.g. based on
X509 certificates, Kerberos tick
ets, plain user names, etc.). This set is termed a
principal
realm
. For each principal realm, there’s a mapping between its principals and one or
more logical security roles that are used in
Java EE

applications. Application servers
offer a plethora of way
s of representing a principal realm, the most common of which are

a local OS user registry, an LDAP server, an RDBMS schema, a Kerberos KDC,
and
a
simple .properties files.

Modern
Java EE

application servers support different security domains or allow us
ers to
define their own ones based on available JAAS login modules. Refer to
the sidebar

What is JAAS?
” for more information on
using
JAAS
in
Java EE
.

When a
Java EE

application is deplo
yed, the deployer assigns the application
modules to
security domains that have been configured in the targeted application server installation.
Typically
,

the components of a
Java EE

module (an EJB .jar module or a Web .war
module) are all assigned to t
he same security domain; some application servers
allow the
components of a given module to be assigned to different security domains, this practice
is generally avoided as it might easily lead to confusion.
Java EE

doesn’t standardize

the
scope of a security domain and leaves it up to vendors. At the moment all high
-
end
application servers allow a security domain to span multiple application server
installations (which typically form a cluster).

Security context propagation and Single
Signon

A
Java EE
application server features three different containers
2
: a Web Container that
hosts JSPs and servlet components, an EJB Container where EJB components are
deployed, and an Application client container (see
the sidebar

Application client
containers
” for more details on this concept). EJB and Web Containers are typically
collocated, and components running in the Web Container can access EJBs of the
corresponding EJB container.

Figure 1 depicts the relationships between the three
containers and various ways in which a client can access a
Java EE
application. For
simplicity’s sake I depicted all enterprise components as running in the same application
server on a single node, thi
s need not always be so, as modern application servers allow
them to be distributed among multiple nodes.

The following are two typical usage scenarios shown in Figure 1 involving access to an
enterprise Java application:

1.

A user accesses a JSP or a servlet

component deployed in a Web Container with a
web browser. He authenticates himself to the Web Container using either 1) a
username and password that his web browser prompts him to enter (Basic HTTP
Authentication) or 2) an X509 certificate that the browse
r lets the user choose from a
pre
-
installed set of user certificates. The servlet component carries out presentation
-
related activities and invokes (using a local invocation in the same JVM or RMI
-
based protocol) an EJB Session component to carry out busin
ess logic
-
related tasks.
To fulfill the business logic task the session bean may invoke an Entity EJB, call on
an EIS with a help of a JCA resource adapter, or carry out some JDBC
-
based data
access.
After completeing

its work, the session c
omponent returns the results of the
processing to the servlet component, which in turn renders them
to
the user in HTML.

The user can then
invoke the servlet or some Web component or JSP again
,
the
application server maintains a session with the user’s browser and doesn’t require re
-
authentication.

2.

A
Java
client application uses either RMI
-
IIOP or RMI
-
JRPM to access the server.
The application prompts the user for a name and credentials and authe
nticates itself to
the Application server with the help of JAAS and
one or more JAAS
its

login module
s

provided by the vendor. For RMI
-
IIOP, the CSIv2 SAS [11] protocol will most likely
be used to communicate authentication data to the server. The cli
ent application
accesses an EJB deployed in an EJB Container. Similar to Scenario 1, the
invoked
EJB
can call other EJBs
or

enterprise services.

The client application goes on to invoke another EJB without
the
need

to re
-
authenticate
the user. Listing 1 presents an example of such a client application for
WebSphere.

Listing 1

final static InitialContext iniCtx = new InitialContext();

// Will prompt the user for a name and credentials

// using a GUI dialog box.

CallbackHandler handl
er = new WSGUICallbackHandlerImpl();




2

There’s also an applet container that is typically embodied by a web browser program.

LoginContext logCtx = new LoginContext("WSLogin", handler);


// Single signon allows to access the container without

// needing to reauthenticate.

logCtx.login();

Subject subject = logCtx.getSubject();


Privilege
dAction bean1Action = new PrivilegedAction() {

public Object run() {


try {


Object homeProxy = iniCtx.lookup("ejb/bean1");


Bean1Home bean1Home = (Bean1Home)


PortableRemoteObject.narrow(homeProxy, Bean1Home.class);



Bean1Remote bean1 = helloHome.create();


bean1.businessMethod1(...);


...


}


catch (CreateException ce) { ... }


catch (RemoteException re) { ... }

}

};

PrivilegedAction bean2Action = new PrivilegedAction() { ... }


// Acce
ss components in the application server on behalf of 'subject'

com.ibm.websphere.security.auth.WSSubject.doAs(subject, bean1Action);

com.ibm.websphere.security.auth.WSSubject.doAs(subject, bean2Action);


// End the logon session.

logCtx.logout();

A lot can

be gathered from the above scenarios and
F
igure

1
.

Firstly, they show that external clients can access components running in the WEB
container by using either HTTP or HTTPS and components hosted in the EJB container
with RMI
-
IIOP or RMI
-
JRMP. They also show that components can use 1) local
invocations in the same JVM, 2) RMI
-
IIOP, or 3) RMI
-
JRMP for inter
-
component
communication. Which of the three can be used depends on the vendor and the
configuration of the application server.

Second
ly, in both examples the clients authenticated themselves to the container before
being able to make use of a component, and the application server propagated the
established client security context when the component invoked other EJBs.

Thirdly, the samp
les demonstrated
Java EE

support for single signon (frequently
abbreviated as SSO), not requiring needless reauthentications on subsequent application
server access. The propagation of a client security context and single signon are two
important security
characteristics of
Java EE
.

Application servers allow the client security context to be propagated if local JVM
invocations, RMI
-
IIOP, or RMI
-
JRMP are used as inter
-
component communication
transports
,

and the component targeted belongs to the same securit
y domain. A client
security context typically consists of a Principle object (whose type depends on the
security domain of a
Java EE

application) and zero or more associated
credentials

presented during authentication.
Java EE
specifies RMI
-
IIOP and the ac
companying
CSIv2 OMG specification as the only interoperable way of propagating the client security
context that must be understood and supported by all compliant application servers (a
security context propagated with RMI
-
JRMP is only meaningful if the ta
rgeted
component runs in an application server of the same vendor). The usage of
CORBA
-
related standards for interoperability among disparate application servers reflects the
CORBA
oriented nature of the early
Java EE
specifications that
remains
the same

to this
day.

The way single signon capabilities are gained depends on the client. For web browser
clients, the web container uses either HTTP Cookies or URL Rewriting to track a session.
In case the browser accesses the container through HTT
PS, SSL Sessions can also be
used. Which of the three mechanisms is available depends on the application server and
its configuration, some servers (e.g. WebSphere) support all three mechanisms, others
not.

In

case of
a Java
application client (see
Listing 1), user authentication credentials are
established during JAAS login
and are then kept in a thread local variable

of the

Java
application thread that execute
s

the
code in Listing 1
.
The credentials will then be used
for each subsequent applicatio
n server access

by the thread until the

logout
statement has
been executed.

Besides the default mode in which
an established
client
security context is propagated
during

inter
-
component communicat
ion, Java EE allows
a given
enterprise component to
specify another identity

(
termed run
-
as identity
)

that will be in effect when the
component accesses
other
en
terprise resources.

Th
e run
-
as

identity

mode is typically used
only in situation
s

whe
re

there's

no

client security context (e.g. message driven beans
,
ejbTimeout

callback methods of enterprise beans that implement the TimedObject
interface
)
.

For

instance in

Opt
imalJ
-
generated J2EE applications
,

we give our use
rs a
warning whenever they mode
led an a
message driven bean or a
n enterprise component
that uses the timer service but didn't specify
a run
-
as identity.


Security in
J2EE 1.4

for web service endpoints

By far
,

the most visible change in
J2EE

1.4 is the introduction of web service endpoints,
which

effectively provides a viable alternative model for component distribution and
interoperability that can compete with
CORBA
. The web service endpoint is a term used
to describe web service components deployed in a
J2EE
container. As I described in th
e
earlier article, a service endpoint can be implemented using a stateless session bean, in
which case it runs in the EJB container, or as a Java class that is registered as a servlet, in
which case it runs in the WEB container and is termed a JAX
-
RPC endp
oint.
Associated
with each service endpoint is its service endpoint interface (SEI)
.
As prescribed by WS
-
I
Basic Profile, J2EE limits SOAP to HTTP and HTTPS as its only two interoperable
underlying transport protocols.

Figure 2 shows the component landsca
pe in
J2EE

1.4. It is analogous in intent to Figure 1
and complements it by emphasizing entries into the application server through web
service endpoints.
Figure 2 has

a number of important differences from Figure 1
:

1.

A web service

component running in the WEB container can be accessed from a
client program running in the application client container, which wasn’t possible in
J2EE
1.3;

2.

A web service component hosted in the EJB container can be reached by an external
non
-
Java client
not only via the C
ORBA

IIOP protocol, but also using the lighter
-
weight
ed

SOAP protocol;

3.

J2EE

components can now use 4 different transports for inter
-
component
communication
s
: 1) local invocations in the same JVM, 2) RMI
-
IIOP, 3) RMI
-
JRMP,
or 4) SOAP.

Let’s take a look at the ramifications of these changes and the mandatory web services
security
-
related features supported by all complaint application servers.

The ability to reach an application server with the new SOAP protocol impacts
authentication an
d
J2EE
requires that the following two authentication mechanisms be
supported:

1.

HTTP Basic Authentication; and

2.

HTTPS Mutual Authentication that uses the certificate presented by a web service
endpoint client during a SSL/TLS handshake.

It’s fairly obvious t
hat HTTP Basic Authentication provides no security unless combined
with HTTPS. It’s also apparent that with these two choices, authentication occurs in the
transport, which has consequences for inter
-
component communication that I will discuss
later.

HTTPS

Mutual Authentication is a very viable authentication scheme. Unfortunately we
learnt that many applications servers, for example JBoss and WebSphere (see
http://jira.jboss.com/jira/browse/JBAS
-
3
019
) do not allow to check client certificates
presented during SSL/TLS handshakes against CRLs (Certificate Revocation Lists) [12],
which severely limits the security of this authentication method for large public enterprise
applications.

For achieving i
ntegrity and confidentiality when communicating with web service
endpoints,
J2EE

provides full support for SSL/TLS. This enables to have the same level
of security with regard to integrity and confidentiality as compared with communication
via RMI
-
IIOP or
RMI
-
JRMP.

The usage of SOAP for inter
-
component communication in
J2EE

might present some
surprises as on most application servers (JBoss, WebSphere), no client security context
propagation is supported
(see
http://jira.jboss.com/jira/browse/JBWS
-
679

for the
situation in JBoss). You may also run into security breaches similar to
http://jira.jboss.com/jira/browse/JBWS
-
675



a security

vulnerability I discovered in
JBoss 4.0.3 and prior that enables to send the credentials of a user accessing a JBoss
application to a non
-
authorized party whenever an enterprise component being accessed
by the user communicates via SOAP with another one.
For
J2EE

applications generated
by our OptimalJ product, we decided to simply prohibit our users from modeling in
t
er
-
component communication
s

via
the
web service endpoints, and I strongly recommend
that you do not use web service endpoints for this purpose

either. If you still need to use
SOAP for inter
-
component invocations, you’ll need to explicitly configure

security
parameters for each { invokingComp/invokingModule,
invokedCompWithServiceEndpoint } pair, called a web service reference, in a vendor
-
s
pecific deployment descriptor.

The situation with single signon is not much better. Listing 2 presents a piece of
a
Java
EE

application client code that accesses a web service endpoint. The code
has the same
purpose
as
Listing 1
, but here I use SOAP instead of IIOP or JRMP to reach the
application server.

Listing 2

InitialContext iniCtx = new InitialContext();


// No use logging in, authentication will occur in the transport

// anyway and no effort to propagate credentials esta
blished in

// the lines commented out below will be made!

//

// UsernamePasswordHandler handler =

// new UsernamePasswordHandler(username, password);

// LoginContext logCtx =

// new LoginContext("client
-
login
-
module
-
name", handler);

//
logCtx.login();


Service srv = (javax.xml.rpc.Service)


iniCtx.lookup("java:comp/env/service/Bean1Service");

Bean1ServiceEndpoint bean1Stub = (Bean1ServiceEndpoint)


srv.getPort(Bean1ServiceEndpoint.class);


// Can use either 1)
Java EE
s
tandard stub properties to specify

// authentication data for HTTP Basic Authentication, or

// 2) Vendor specific extensions to specify a cerificate

// for HTTPS Mutual Authentication


Stub stub = (Stub) port;


// Portable code for HTTP Basic Authenticat
ion.

stub._setProperty("javax.xml.rpc.security.auth.username", "Name");

stub._setProperty("javax.xml.rpc.security.auth.password", "Password");


// JBoss specific code for HTTPS Mutual Authentication.

// stub._setProperty("org.jboss.webservice.keyStore", ke
yStore);

// stub._setProperty("org.jboss.webservice.keyStorePassword",

// "keyStorePassword");

// stub._setProperty("org.jboss.webservice.keyStoreType", "JKS");

// stub._setProperty("org.jboss.webservice.trustStore", trustStore);

// stub.
_setProperty("org.jboss.webservice.trustStorePassword",

// "trustStorePassword");

// stub._setProperty("org.jboss.webservice.trustStoreType", "JKS");



bean1Stub.businessMethod1(...);

...


// End the logon session.

// logCtx.logout();


You can see from the code
that you cannot benefit from JAAS for authentication and
SSO
,

because
you need to specify authentication data for each invocation.
(
Uncommenting JAAS login statements would be futile



even though it will cause the
crea
tion of a login session with the server, no attempt will be made to place established
credentials in SOAP messages

generated by calls to the enterprise components
).
Fortunately most application servers allow you to
re
move authentication specific data
from

your code and
put it
into a deployment descriptor,

but that still falls short of proper
SSO support.


Example 2 shows you a piece of JBoss client deployment descriptor holding
the
necessary authentication data. Th
e advantage of the deployment descriptor approach is
that it enables you specify security parameters for each {
invokingComp/invokingModule, invokedCompWithServiceEndpoint } pair only once
and do not needlessly clutter the accompanying Java code for each i
nvocation.

Example 2

<service
-
ref>


<service
-
ref
-
name>service/Bean1Service</service
-
ref
-
name>


<port
-
component
-
ref>


<service
-
endpoint
-
interface>Bean1ServiceEndpoint</service
-
endpoint
-
interface>


<call
-
property>


<prop
-
name>javax.xml.rpc.secur
ity.auth.username</prop
-
name>


<prop
-
value>Name</prop
-
value>


</call
-
property>


<call
-
property>


<prop
-
name>javax.xml.rpc.security.auth.password</prop
-
name>


<prop
-
value>Password</prop
-
value>


</call
-
property>


</port
-
component
-
ref
>

</service
-
ref>

Security for
Web
service endpoints


the future

I
f

you are familiar with recent developments in the area of web services security
standards, you might wonder why SSO and security context propagation are still a
problem. The

answer is simple: at the time when
Java EE

1.4 was finalized (November
2003) there was only one specification that could address the problem of security context
propagation and SSO at the message level


OASIS Web Services Security (WS
-
Security) standard
[13]. And that standard was then in a draft state, which precluded its
incorporation in the spec. Since then WSS has become an OASIS standard and moved
from version 1.0 to 1.1. Besides
,

two new specifications that could potentially address the
problem of w
eb services SSO have appeared: WS
-
Trust [14], WS
-
SecureConversation
[15]. They are both currently in a public draft state and none of the
application servers
covered in this article

supports them.

It
’s

logical that Java™ 2 Platform, Ente
rprise Edition, v5.0, which must have been
released by the time of you reading this, should offer some support for WS
-
Security to
address the problem of security context propagation. Surprisingly Java EE 5.0 contains
almost no changes with regard to web se
rvices security and doesn’t address the problems
I delineated in the previous section.

Fortunately IBM
,

BEA
, and JBoss

already support the WS
-
Security standard in their
WebSphere 6.0.x
,

WebLogic 9.1
, and JBoss 4.0.4

products. WebLogic even puts it

in use
for security context propagation and SSO while WebSphere limits itself to authentication,
encryption and digital signing.

WebSphere
,

WebLogic
, and JBoss

implement Version 1.0 of the WS
-
Security standard
and support its following specifications:



SOAP Message Security;



UsernameToken Profile;



X.509 Certificate Token Profile;

On top of it WebLogic
implements:



SAML Token Profile.

which allows it to offer web services SSO and security context propagation experience.

In addition to the previously mentioned SSO qualities for WebLogic,
the
servers allow to
achieve the following additional security c
haracteristics
with the help

of WS
-
Security:

1.

Authentication at the SOAP message level using plaintext name passwords and X.509
Version 3 certificates;

2.

On WebLogic, authentication at the SOAP message level using SAML tokens;

3.

On WebSphere, authenticat
ion at the SOAP message level using LTPA tokens;

4.

Encryption of SOAP messages or parts thereof using symmetric cryptography. Secret
keys can be encrypted and placed into messages too. Essentially,
the
application
servers support
most
required and s
ome optional encryption
-
related algorithms as
specified in the XML Encryption Syntax and Processing specification [16], which the
WS
-
Security standard builds upon.

5.

Digital signing and verifying of SOAP messages or portions thereof. This is an
important ite
m as it allows to achieve non
-
repudiation


something that is not
possible with RMI
-
IIOP and RMI
-
JRMP based transports and wasn’t possible in the
Java EE

security model in the past.
The

application servers implement
most
required
portions of th
e XML
-
Signature Syntax and Processing specification [17], which also
underlies the WS
-
Security standard.

6.

Means of defeating replay attacks by using nonces
and timestamps in SOAP headers.

As I mentioned earlier,
Java
EE

v 1.4/5.0
is
silent on the subject o
f the WS
-
Security
standard
.

One unpleasant consequence of that is that you need to use container
-
specific
deployment descripror
s

to specify

all WS
-
Security related

information of your
application, which o
bviously limits the portability of your application.

WebLogic is an
interesting exception, they chose to

adopt WS
-
Policy

[18]

as a standard means of
specifying WS
-
Security related
configuration of web service endpoints (
Microsoft has
done the same in their .
NET framework
)
. JBoss is also m
oving in the direct
ion of
embracing WS
-
Policy (
see
http://jira.jboss.com/jira/browse/JBWS
-
856

for more
information
).

Lack of WS
-
Security support in Java EE 1.4/5.0 also

means that Sun Micsrosystem's
technology conform
ance kits for Java EE (that an application server must pass in order
for it to be declared compliant) exclude any related testing, allowing vendors to deviate
from one another in their WS
-
Security implemetation.

As is the case with most crucial web services specifications, the WS
-
I Consortium (the
producer of the Basic Profile


a specif
ication that ensures interoperability among web
service components today) has taken on an initiative of defining the subset of the WS
-
Security standard and its constituent specifications that must be supported by all vendors
in the same fashion. This effor
t is know
n

as the Basic Security Profile [
19
] and is now in
a draft state. Until it is completed and all vendors have incorporated it into their products,
interoperability issues among vendors are inevitable

(this is largely

d
ue to the

extensiveness

the

WS
-
Security standard and a plethora of decisions that a vendor needs
to make when implementing it
)
.
The following article gives you an idea of what kind of
problems you might run into if you use products from different vendors:
http://www
-
128.ibm.com/developerworks/webservices/library/ws
-
was
-
net/index.html?ca=drs
-
%20%20%20%20%20%20%20%20%20%20%20%20%20
%20%20Articles
.

Conclusion

The new web services object distributed model in Java Enterprise Edition v 1.4/5.0
clearly has the potential of supplanting RMI
-
IIOP and RMI
-
JRMP in Enterprise Java as
the main object distribution protocol that offers the same o
r better security services. At
the moment, however, the required level of support that the Java Enterprise Edition v
.

1.4/5.0 specification
is clearly non
-
sufficient to make it happen. Still, seeing the current
trends in the industry an
d more and more vendors committing themselves to WS
-
Security
and its Basic Security Profile counterpart, it is more a question of when than if.

The fact that 1) support for WS
-
I Basic Security Profile is not yet prevalent in
Java EE

applications servers a
vailable in the market
and that 2) the profile is still subject to
change, has inevitable consequence to those who develop portable
Java EE

applications.
If the por
tability of you
r

application is a concern
, you would be better off limiting
yourself to the guaranteed Java EE 1.4/5.0 web services security features and keeping off
WS
-
Security for a time. This is the approach we settled for in our forthcoming Opti
malJ
product as we need to shield our user from the specifics of a particular vendor
implementation.

Sidebar
1: What is JAAS?

JAAS stands for Java Authentication and Authorization Service. It provides a Java
implementation of the Pluggable Authenti
cation Module (PAM) framework, which was
pioneered in the Solaris operating system [9]. Modern application servers use JAAS at
least for authentication of principles accessing resources running in the server. JAAS is
also heavily used by Java clients runni
ng in an application container as a means of
authenticating themselves to the application server and benefiting from the single signon
capability. The article “JAAS in the Enterprise” [10] gives a pretty good idea of the
future direction this specification

is likely to take in upcoming releases of Java Enterprise
Edition.

Sidebar
2: Application client containers

Application client containers are a means of allowing access to components and services
of a
Java EE

application server to remote J2SE clie
nts. Despite its rather imposing name,
an application client container can be nothing more than a set of .jar libraries that enable
a standalone Java application to access the JNDI tree of an
Java EE

application server,
whereby getting access to enterprise

beans as well as other enterprise services such as
JMS, container
-
managed JDBC data sources, JavaMail, etc. For JBoss AS the set of .jar
libraries is all that is required to set up a client container on a host where J
ava
SE runtime
is installed (see
http://wiki.jboss.org/wiki/Wiki.jsp?page=J2EEClient

for more
information). For WebSphere and WebLogic, the setup is more involved


both require
that a client host have access to the AS instal
lation and provide an application client
launch program that must be used to execute a client program.

References

[1].

Moving to SOA in J2EE 1.4:
http://java.sys
-
con.com/read/180362.htm

[2].

Java™ 2 Platform E
nterprise Edition Specification, v1.4:
http://java.sun.com/j2ee/j2ee
-
1_4
-
fr
-
spec.pdf

[3].

Java™ 2 Platform, Enterprise Edition, v5.0:
http://jcp.org/aboutJava/communityprocess/pr/jsr244/

[4].

The SSL Protocol, Version 3.0:
http://home.netscape.com/eng/ssl3/draft302.txt

[5].

RFC 2246: The TLS Protocol, Version 1.0:
http://www.ietf.org/rfc/rfc2246.txt

[6].

RFC 2459: Internet X.509 Public Key Infrastructure, Certificate and CRL Profile:
http://www.ietf.org/rfc/rfc2459.txt

[7].

RFC 2712: A
ddition of Kerberos Cipher Suites to Transport Layer Security (TLS):
http://www.ietf.org/rfc/rfc2712.txt

[8].

RFC 2945: The SRP Authentication and Key Exchange System:
http://www.ietf.org/rfc/rfc2945.txt

[9].

Making Login Services Independent of Authentication Technologies:
http://java.sun.com/security/jaas/doc/pam.html

[10].

JAAS in the Enterprise:
http://jdj.sys
-
con.com/read/171477.htm

[11].

Common Secure Interoperability, Version 2:
http://www.omg.org/technology/document
s/formal/omg_security.htm#CSIv2

[12].

Certificate and Certificate Revocation List (CRL) Profile:
http://www.ietf.org/rfc/rfc3280.txt

[13].

OASIS Web Services Security (WSS):
http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=wss

[14].

Web Services Trust Language (WS
-
Trust):
ftp://www6.software.ibm.com/sof
tware/developer/library/ws
-
trust.pdf

[15].

Web Services Secure Conversation Language (WS
-
SecureConversation):
ftp://www6.software.ibm.com/software/developer/library
/ws
-
secureconversation.pdf

[16].

XML Encryption Syntax and Processing:
http://www.w3.org/TR/xmlenc
-
core/

[17].

XML
-
Signature Syntax and Processing:
http://www.w3.org
/TR/xmldsig
-
core/

[18].

Web Services Policy Framework (WSPolicy)
:
http://specs.xmlsoap.org/ws/2004/09/policy/ws
-
policy.pdf

[19].

Basic Security Profile:
http://www.ws
-
i.org/deliverables/workinggroup.aspx?wg=basicsecurity