Red Hat JBoss Fuse Service Works 6 Security Guide

Transcription

Red Hat JBoss Fuse Service Works 6
Security Guide
Use this guide to find out more about security for Red Hat JBoss Fuse
Service Works.
Vidya Iyengar
David Le Sage
Anshu Mahajan
Red Hat JBoss Fuse Service Works 6 Security Guide
Use this guide to find out more about security for Red Hat JBoss Fuse
Service Works.
Vidya Iyengar
viyengar@redhat.co m
David Le Sage
Red Hat Engineering Co ntent Services
dlesage@redhat.co m
Anshu Mahajan
anmahaja@redhat.co m
Legal Notice
Co pyright © 20 14 Red Hat, Inc..
This do cument is licensed by Red Hat under the Creative Co mmo ns Attributio n-ShareAlike 3.0
Unpo rted License. If yo u distribute this do cument, o r a mo dified versio n o f it, yo u must pro vide
attributio n to Red Hat, Inc. and pro vide a link to the o riginal. If the do cument is mo dified, all Red
Hat trademarks must be remo ved.
Red Hat, as the licenso r o f this do cument, waives the right to enfo rce, and agrees no t to assert,
Sectio n 4 d o f CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shado wman lo go , JBo ss, MetaMatrix, Fedo ra, the Infinity
Lo go , and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o ther
co untries.
Linux ® is the registered trademark o f Linus To rvalds in the United States and o ther co untries.
Java ® is a registered trademark o f Oracle and/o r its affiliates.
XFS ® is a trademark o f Silico n Graphics Internatio nal Co rp. o r its subsidiaries in the United
States and/o r o ther co untries.
MySQL ® is a registered trademark o f MySQL AB in the United States, the Euro pean Unio n and
o ther co untries.
No de.js ® is an o fficial trademark o f Jo yent. Red Hat So ftware Co llectio ns is no t fo rmally
related to o r endo rsed by the o fficial Jo yent No de.js o pen so urce o r co mmercial pro ject.
The OpenStack ® Wo rd Mark and OpenStack Lo go are either registered trademarks/service
marks o r trademarks/service marks o f the OpenStack Fo undatio n, in the United States and o ther
co untries and are used with the OpenStack Fo undatio n's permissio n. We are no t affiliated with,
endo rsed o r spo nso red by the OpenStack Fo undatio n, o r the OpenStack co mmunity.
All o ther trademarks are the pro perty o f their respective o wners.
Abstract
This guide teaches users ho w to secure Red Hat JBo ss Fuse Service Wo rks.
T able of Cont ent s
T able of Contents
.Preface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. . . . . . . . . .
⁠1. Do c ument Co nventio ns
3
⁠1.1. Typ o g rap hic Co nventio ns
3
⁠1.2. Pull-q uo te Co nventio ns
4
⁠1.3. No tes and Warning s
5
⁠2 . G etting Help and G iving Feed b ac k
5
⁠2 .1. Do Yo u Need Help ?
⁠2 .2. We Need Feed b ac k!
5
6
. .hapt
⁠C
. . . .er
. .1. .. Swit
. . . .chYard
. . . . . . .Securit
. . . . . .y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. . . . . . . . . .
⁠1.1. Ab o ut Switc hYard Sec urity
7
⁠1.2. Co nfig uring Sec urity fo r Switc hYard
8
⁠1.3. Switc hYard Sec urity Co nfig uratio n
8
⁠1.4. Us ing Sec urity Elements and Attrib utes
9
⁠1.5. Sec urity
10
⁠1.6 . Callb ac k Hand lers
⁠1.7. Lo g in Mo d ules
10
11
⁠1.8 . Switc hYard Sec urity Q uic ks tarts
⁠1.9 . Sec ure Ways o f Running Red Hat JBo s s Fus e Servic e Wo rks
11
12
. .hapt
⁠C
. . . .er
. .2. .. Pat
. . . ch
. . .Inst
. . . allat
. . . . ion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. 3. . . . . . . . . .
⁠2 .1. Ab o ut Patc hing Mec hanis ms
⁠2 .2. Sub s c rib e to Patc h Mailing Lis ts
13
13
⁠2 .3. Ins tall Patc hes in z ip fo rm
⁠2 .4. Severity and Imp ac t Rating o f JBo s s Sec urity Patc hes
14
15
. .hapt
⁠C
. . . .er
. .3.
. .WS. . . Securit
. . . . . . .y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. 7. . . . . . . . . .
⁠3 .1. WS-Sec urity O verview
⁠3 .2. JBo s s WS-Sec urity Sup p o rt
17
17
⁠3 .3. Ap ac he CXF WS-Sec urity Imp lementatio n
⁠3 .3.1. WS-Sec urity Po lic y Sup p o rt
17
18
⁠3 .3.2. JBo s s WS Co nfig uratio n Ad d itio ns
⁠3 .3.3. Ap ac he CXF Anno tatio ns
19
20
⁠3 .4. Enab le WS-Sec urity
⁠3 .5. Samp le WS-Sec urity Co nfig uratio ns
⁠3 .6 . Sig nature and Enc ryp tio n Sup p o rt
⁠3 .7. Samp le End p o int Co nfig uratio ns
21
21
22
22
⁠3 .8 . Samp le Client Co nfig uratio ns
⁠3 .9 . End p o int Serving Multip le Clients
⁠3 .10 . Samp le CXF Interc ep to r Co nfig uratio ns
29
30
30
. .hapt
⁠C
. . . .er
. .4. .. S. . RAMP
. . . . . .Securit
. . . . . . y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
...........
⁠4 .1. S-RAMP Bro ws er
32
⁠4 .1.1. S-RAMP Bro ws er Authentic atio n
⁠4 .1.2. S-RAMP Bro ws er Autho riz atio n
⁠4 .2. S-RAMP Server
⁠4 .2.1. S-RAMP Server Autho riz atio n
32
32
32
33
. .hapt
⁠C
. . . .er
. .5.
. .Policy
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
...........
⁠5 .1. Ab o ut Po lic y
⁠5 .2. Co nfig uring Po lic y
⁠5 .3. Interac tio n Po lic y
⁠5 .4. Imp lementatio n Po lic y
34
34
35
35
1
Red Hat JBoss Fuse Service Works 6 Securit y G uide
⁠5 .5. Trans ac tio n Po lic y
35
⁠5 .5.1. Trans ac tio n Interac tio n Po lic y
⁠5 .5.2. Trans ac tio n Imp lementatio n Po lic y
⁠5 .6 . Sec urity Po lic y
⁠5 .6 .1. Sec urity Interac tio n Po lic y
35
36
37
38
⁠5 .6 .2. Sec urity Imp lementatio n Po lic y
⁠5 .6 .3. Setting Sec urity Po lic y
⁠5 .6 .4. Sec urity Pro c es s ing
39
39
39
. . . . . . . . .Hist
Revision
. . . ory
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. 1. . . . . . . . . .
2
Preface
Preface
1. Document Convent ions
This manual uses several conventions to highlight certain words and phrases and draw attention to
specific pieces of information.
1.1. T ypographic Convent ions
Four typographic conventions are used to call attention to specific words and phrases. These
conventions, and the circumstances they apply to, are as follows.
Mo no -spaced Bo l d
Used to highlight system input, including shell commands, file names and paths. Also used to
highlight keys and key combinations. For example:
To see the contents of the file my_next_bestsel l i ng _no vel in your current
working directory, enter the cat my_next_bestsel l i ng _no vel command at the
shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key, all presented in mono-spaced bold and
all distinguishable thanks to context.
Key combinations can be distinguished from an individual key by the plus sign that connects each
part of a key combination. For example:
Press Enter to execute the command.
Press C trl +Al t+F2 to switch to a virtual terminal.
The first example highlights a particular key to press. The second example highlights a key
combination: a set of three keys pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values
mentioned within a paragraph will be presented as above, in mo no -spaced bo l d . For example:
File-related classes include fi l esystem for file systems, fi l e for files, and d i r for
directories. Each class has its own associated set of permissions.
Pro p o rt io n al B o ld
This denotes words or phrases encountered on a system, including application names; dialog-box
text; labeled buttons; check-box and radio-button labels; menu titles and submenu titles. For
example:
Choose Syst em → Pref eren ces → Mo u se from the main menu bar to launch
Mo u se Pref eren ces. In the Butto ns tab, select the Left-hand ed mo use check
box and click C l o se to switch the primary mouse button from the left to the right
(making the mouse suitable for use in the left hand).
To insert a special character into a g ed it file, choose Ap p licat io n s →
Accesso ries → C h aract er Map from the main menu bar. Next, choose Search →
Fin d … from the C h aract er Map menu bar, type the name of the character in the
Search field and click Next. The character you sought will be highlighted in the
3
C haracter T abl e. D ouble-click this highlighted character to place it in the T ext
to co py field and then click the C o py button. Now switch back to your document
and choose Ed it → Past e from the g ed it menu bar.
The above text includes application names; system-wide menu names and items; application-specific
menu names; and buttons and text found within a GUI interface, all presented in proportional bold
and all distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or
variable text. Italics denotes text you do not input literally or displayed text that changes depending
on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@ domain.name at a
shell prompt. If the remote machine is exampl e. co m and your username on that
machine is john, type ssh jo hn@ exampl e. co m.
The mo unt -o remo unt file-system command remounts the named file system.
For example, to remount the /ho me file system, the command is mo unt -o remo unt
/ho me.
To see the version of a currently installed package, use the rpm -q package
command. It will return a result as follows: package-version-release.
Note the words in bold italics above: username, domain.name, file-system, package, version and
release. Each word is a placeholder, either for text you enter when issuing a command or for text
displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and
important term. For example:
Publican is a DocBook publishing system.
1.2. Pull-quot e Convent ions
Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mo no -spaced ro man and presented thus:
books
books_tests
Desktop
Desktop1
documentation drafts mss
downloads
images notes
photos
scripts
stuff
svgs
svn
Source-code listings are also set in mo no -spaced ro man but add syntax highlighting as follows:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,

struct kvm_assigned_pci_dev *assigned_dev)

{

int r = 0;

struct kvm_assigned_dev_kernel *match;
mutex_lock(& kvm->lock);

match = kvm_find_assigned_dev(& kvm->arch.assigned_dev_head,
assigned_dev->assigned_dev_id);
if (!match) {
printk(KERN_INFO "%s: device hasn't been assigned

4
Preface
before, "

"so cannot be deassigned\n", __func__);
r = -EINVAL;
goto out;

}

kvm_deassign_device(kvm, match);

kvm_free_assigned_device(kvm, match);
o ut:

mutex_unlock(& kvm->lock);
return r;

}
1.3. Not es and Warnings
Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
Note
Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should
have no negative consequences, but you might miss out on a trick that makes your life easier.
Important
Important boxes detail things that are easily missed: configuration changes that only apply to
the current session, or services that need restarting before an update will apply. Ignoring a
box labeled “ Important” will not cause data loss but may cause irritation and frustration.
Warning
Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
2. Get t ing Help and Giving Feedback
2.1. Do You Need Help?
If you experience difficulty with a procedure described in this documentation, visit the Red Hat
Customer Portal at http://access.redhat.com. Through the customer portal, you can:
search or browse through a knowledgebase of technical support articles about Red Hat products.
submit a support case to Red Hat Global Support Services (GSS).
access other product documentation.
5
Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and
technology. You can find a list of publicly available mailing lists at
https://www.redhat.com/mailman/listinfo. Click on the name of any mailing list to subscribe to that list
or to access the list archives.
2.2. We Need Feedback!
If you find a typographical error in this manual, or if you have thought of a way to make this manual
better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/
against the product R ed H at JB o ss Fu se Service Wo rks.
When submitting a bug report, be sure to mention the manual's identifier: Security_Guide
If you have a suggestion for improving the documentation, try to be as specific as possible when
describing it. If you have found an error, please include the section number and some of the
surrounding text so we can find it easily.
6
⁠Chapt er 1 . Swit chYard Securit y
Chapter 1. SwitchYard Security
SwitchYard services can be secured by:
Specifying a list of security policies that are required for that service.
Configuring application-level security processing details for the services within a domain.
Configuring system-level security processing details.
Storing sensitive information, such as passwords, in the JBoss AS password vault.
For information on SAML (Security Assertion Markup Language) and Java Security Manager, refer
JBoss Enterprise Application Platform 6.1.1 Security Guide.
See Also :
Section 5.6, “ Security Policy”
Section 1.3, “ SwitchYard Security Configuration”
Section 1.7, “ Login Modules”
Report a bug
1.1. About Swit chYard Securit y
SOA architecture involves applications to be exposed as services. These services must be protected
against security vulnerabilities such as a SQL injection attack, XML entity expansion, and denial of
service attack. The security implementation covers these security concerns and also provides the
ability to monitor usage of services in SOA. However, you need to address the security concerns as
an application developer if you are building your application on top of the product. For more
information on such security concerns, refer https://www.owasp.org/index.php/Top_10_2013-Top_10.
SwitchYard services are secured in the following ways:
Specify a list of security policies that are required for that service in the SwitchYard application
descriptor (swi tchyard . xml ). Edit the swi tchyard . xml file using the SwitchYard editor
plugin and specify the security policy by using the requires attribute of a component service
definition as shown below:
<service name="WorkService" requires="authorization
clientAuthentication confidentiality">
You can configure the security processing details for the services within a domain in the following
ways:
Select the Service for a component and view the P ro perti es Vi ew in the SwitchYard
editor.
Hover over the Service for a component. A list of tools including the Pro p ert y Sh eet appears.
It contains the security information.
Ensure Autho ri zati o n, C l i ent Authenti cati o n and C o nfi d enti al i ty are checked.
7
This guide provides information on Red Hat JBoss Fuse Service Works security. For information on
the security of underlying application platform, refer JBoss Enterprise Application Platform 6.1.1
Security Guide.
Report a bug
1.2. Configuring Securit y for Swit chYard
All services within a domain can define or share their own security configuration, which is specified
in MET A-INF/swi tchyard . xml file.
<sy:switchyard>
<sca:composite ...>
<component ...>
...
<service ... sy:security="security-name">
...
</service>
<reference ... sy:security="default">
...
</reference>
</component>
<sca:composite>
<domain>
<securities>
<security callbackHandler="callback-handler-class-name"
name="security-name" rolesAllowed="users, administrators" runAs="leaders"
securityDomain="jaas-domain-name">
<properties>
<property name="property-name" value="propertyvalue"/>
</properties>
</security>
</securities>
</domain>
</sy:switchyard>
Report a bug
1.3. Swit chYard Securit y Configurat ion
All services within a domain share the same security configuration, which is specified in MET AINF/swi tchyard . xml :
<switchyard>
<domain>
moduleName="jaas-domain-name" rolesAllowed="users, administrators"
runAs="leaders">
<properties>
<property name="property-name" value="property-value"/>
8
</properties>
</security>
</domain>
</switchyard>
T h e <secu rit y> elemen t
This is an optional element. If not specified, the callbackHandler and moduleName attributes
described below will fallback to their default values.
T h e callb ackH an d ler at t rib u t e
This is an optional attribute. If not specified, a default value of
o rg . swi tchyard . securi ty. cal l back. NameP asswo rd C al l backHand l er will be
used.
T h e mo d u leN ame at t rib u t e
This is an optional attribute. If not specified, a default value of other will be used. The value
maps to a JAAS security domain name.
T h e ro lesAllo wed at t rib u t e
This is an optional attribute. If specified, and if a Service has an authorization security
policy requirement, the authenticated user must be in one of the roles listed. The value is a
comma-separated list of roles (whitespace gets trimmed).
T h e ru n As at t rib u t e
This is an optional attribute. If specified, the value of this attribute will be added as a role to
the authenticated user.
T h e <p ro p ert ies> an d <p ro p ert y> elemen t s
A <security> element can optionally specify a <properties> element. This can be adjusted to
specify zero to many (0..*) <property> elements. Each <property> element requires a name
and a value attribute.
Note
The list of specified name/value properties is made available to the SwitchYard Security
configuration, as well as the configured callbackHandler. Some CallbackHandlers require
configuration information beyond what can be assumed in a no-argument constructor. See
the individual CallbackHandler implementations for details.
Report a bug
1.4 . Using Securit y Element s and At t ribut es
T h e <co mp o n en t ><service> an d <co mp o n en t ><ref eren ce> secu rit y At t rib u t e
Component Services and Component References can specify an optional sy:security
attribute. This attribute points to a named <security> element in the domain section. If not
defined, use the default value.
T h e callb ackH an d ler At t rib u t e
9
This is an optional attribute. If not specified, use the default value of
o rg . swi tchyard . securi ty. cal l back. NameP asswo rd C al l backHand l er.
T h e n ame At t rib u t e
This is an optional attribute. If not specified, use the default value of default. Component
Services and Component References point to this name.
T h e ro lesAllo wed At t rib u t e
This is an optional attribute. If specified, and if a Service has an authorization security
policy requirement, the authenticated user must be in one of the roles listed.
T h e ru n As At t rib u t e
This is an optional attribute. If specified, add the value of this attribute as a role to the
authenticated user.
T h e secu rit yD o main At t rib u t e
This is an optional attribute. If not specified, use the default value.
T h e <p ro p ert ies> an d <p ro p ert y> Elemen t s
A <security> element can optionally specify a <properties> element, which can optionally
specify zero to many <property> elements. Each <property> element has two required
attributes: name and value. The list of specified name/value properties are made available
to the SwitchYard Security configuration, as well as the configured callbackHandler.
T h e <secu rit ies> Elemen t
This is an optional element. Contains any number of <security> elements. If not defined, use
the default security configuration.
T h e <secu rit y> Elemen t
This is an optional element. If not specified, the callbackHandler, name, and
securityD omain attributes will fallback to their default values.
Report a bug
1.5. Securit y
SwitchYard allows you to make services secure by specifying a list of security properties for a
service. You may also configure the security processing details for services within a domain.
Report a bug
1.6. Callback Handlers
The following is a list of available CallbackHandlers within the
o rg . swi tchyard . securi ty. cal l back Java package:
N amePasswo rd C allb ackH an d ler
Provides name and password credentials to a configured LoginModule stack.
ST ST o ken C allb ackH an d ler
10
Provides assertion credentials to a configured LoginModule stack.
ST SIssu eC allb ackH an d ler
Utilizes the NamePasswordCallbackHandler and the STSTokenCallbackHandler to provide
name, password and assertion credentials to a configured LoginModule stack.
C ert if icat eC allb ackH an d ler
Provides Certificate credentials to a configured LoginModule stack.
Report a bug
1.7. Login Modules
Login modules provide user information including logins, passwords and roles within JBoss Fuse
Service Works. They provide services with customizable user authentication and the ability to reuse
existing login modules defined for the platform.
JBoss Fuse Service Works bundles various PicketBox (underlying security capability)
LoginModules, as well as various PicketLink (federated trust security capability) LoginModules. They
can be stacked underneath a single security domain.
For more information on Login Module examples, refer JBoss Enterprise Application Platform 6.1
Security Guide.
Report a bug
1.8. Swit chYard Securit y Quickst art s
The SwitchYard distribution contains security examples in the form of quickstart demos. The
following is a brief description of each of the quickstarts:
p o licy- secu rit y- b asic
This quickstart exposes a bean service through a soap binding. Confidentiality is provided
via SSL, and client authentication via a HTTP Basic Authorization header. See the
Readme.md file for details.
p o licy- secu rit y- b asic- p ro p ag at e
This quickstart is similar to policy-security-basic, however the bean service additionally
invokes a different back end bean service which also has security policy requirements. The
client's security context (authenticated subject and credentials) is propagated to this
secondary service.
p o licy- secu rit y- cert
via SSL, and client authentication via an X509 Certificate. See the Readme.md file for
details.
p o licy- secu rit y- saml
via SSL, and client authentication via a SAML assertion in the form of a token retrieved from
PicketLink STS. See the Readme.md file for details.
11
p o licy- secu rit y- wss- sig n en cryp t
This quickstart exposes a bean service through a soap binding. Proper Signature and
Encryption are enforced by JBossWS-CXF. See the Readme.md file for details.
p o licy- secu rit y- wss- u sern ame
via SSL, and client authentication via a WS-Security UsernameToken which is handled by
JBossWS-CXF. See the Readme.md file for details.
Report a bug
1.9. Secure Ways of Running Red Hat JBoss Fuse Service Works
Enabling the Java Security Manager (JSM) to sandbox the evaluation of MVEL may introduce a
performance hit in high load environments. Following are some secure ways of running Red Hat
JBoss Fuse Service Works:
If you run Red Hat JBoss Fuse Service Works without Run-Time Governance, you can disable
JSM as it does not introduce MVEL security risks.
If you need Run-Time Governance in high performance environment, Red Hat recommends
running Run-Time Governance in a separate JVM. The JVM instance running Run-Time
Governance must have JSM enabled, whereas other application server instances can run without
JSM.
If you are working on testing and development environments without high loads, it is okay to run
one JVM with the server, Run-Time Governance, and JSM enabled as the performance hit is not
dramatic.
Warning
Red Hat does not recommend running the server with Run-Time Governance enabled and JSM
disabled in one JVM instance, as this is not secure.
Report a bug
12
⁠Chapt er 2 . Pat ch Inst allat ion
Chapter 2. Patch Installation
2.1. About Pat ching Mechanisms
JBoss patches are released in two forms.
Asynchronous updates: one-off patches which are released outside the normal update cycle of
the existing product. These may include security patches, as well as other one-off patches
provided by Red Hat Global Support Services (GSS) to fix specific issues.
Planned updates: These include cumulative patches, as well as micro, minor or major upgrades
of an existing product. Cumulative patches include all previously developed asynchronous
updates for that version of the product.
D eciding whether a patch is released as part of a planned update or an asynchronous update
depends on the severity of the issue being fixed. An issue of low impact is typically deferred, and is
resolved in the next cumulative patch or minor release of the affected product. Issues of moderate or
higher impact are typically addressed in order of importance as an asynchronous update to the
affected product, and contain a fix for only a specific issue.
Cumulative and security patches for JBoss products are distributed in two forms: zip (for all
products) and RPM (for a subset of products).
Important
A JBoss product installation must always only be updated using one patch method: either zip
or RPM patches. Not all patches will be available via RPM, therefore customers using the RPM
installation will not be able to update via the zip patch, and will not have the option to patch
their instance.
Security updates for JBoss products are provided by an erratum (for both zip and RPM methods).
The erratum encapsulates a list of the resolved flaws, their severity ratings, the affected products,
textual description of the flaws, and a reference to the patches. Bug fix updates are not announced
via an erratum.
For more information on how Red Hat rates JBoss security flaws, refer to: Section 2.4, “ Severity and
Impact Rating of JBoss Security Patches”
Red Hat maintains a mailing list for notifying subscribers about security related flaws. See
Section 2.2, “ Subscribe to Patch Mailing Lists”
Report a bug
2.2. Subscribe t o Pat ch Mailing List s
Su mmary
The JBoss team at Red Hat maintains a mailing list for security announcements for Red Hat JBoss
Enterprise Middleware products. This section covers what you need to do to subscribe to this list.
Prereq u isit es
None
13
Pro ced u re 2.1. Su b scrib e t o t h e JB o ss Wat ch List
1. Click the following link to go to the JBoss Watch mailing list page: JBoss Watch Mailing List.
2. Enter your email address in the Subscri bi ng to Jbo ss-watch-l i st section.
3. [You may also wish to enter your name and select a password. D oing so is optional but
recommended.]
4. Press the Subscri be button to start the subscription process.
5. You can browse the archives of the mailing list by going to: JBoss Watch Mailing List
Archives.
R esu lt
After confirmation of your email address, you will be subscribed to receive security related
announcements from the JBoss patch mailing list.
Report a bug
2.3. Inst all Pat ches in z ip form
Su mmary
JBoss bug fix patches are distributed in zip format. This task describes the steps you need to take to
install the patches (security or bug fixes) via the zip format.
Prereq u isit es
Valid access and subscription to the Red Hat Customer Portal.
A current subscription to a JBoss product installed in a zip format.
Pro ced u re 2.2. Ap p ly a p at ch t o a JB o ss p ro d u ct via t h e z ip met h o d
Security updates for JBoss products are provided by an erratum (for both zip and RPM methods).
The erratum encapsulates a list of the resolved flaws, their severity ratings, the affected products,
textual description of the flaws, and a reference to the patches. Bug fix updates are not announced
via an erratum.
For zip distributions of JBoss products, the ERRATA includes a link to a URL on the Customer Portal
where the patch zip can be downloaded. This download contains the patched versions of existing
JBoss products and only includes the files that have been changed from the previous install.
Warning
Before installing a patch, you must backup your JBoss product along with all customized
configuration files.
1. Get notified about the security patch either via being a subscriber to the JBoss watch mailing
list or by browsing the JBoss watch mailing list archives.
14
⁠Chapt er 2 . Pat ch Inst allat ion
Note
Only security patches are announced on the JBoss watch mailing list.
2. Read the ERRATA for the security patch and confirm that it applies to a JBoss product in your
environment.
3. If the security patch applies to a JBoss product in your environment, then follow the link to
download the patch from the Red Hat Customer Portal.
4. The downloadable zip file from the customer portal will contain all the files required to fix the
security issue or bug. D ownload this patch zip file in the same location as your JBoss
product.
5. Unzip the patch file in the same location where the JBoss product is installed. The patched
versions overwrite the existing files.
R esu lt
The JBoss product is patched with the latest update using the zip format.
Report a bug
2.4 . Severit y and Impact Rat ing of JBoss Securit y Pat ches
To communicate the risk of each JBoss security flaw, Red Hat uses a four-point severity scale of low,
moderate, important and critical, in addition to Common Vulnerability Scoring System (CVSS)
version 2 base scores which can be used to identify the impact of the flaw.
T ab le 2.1. Severit y R at in g s o f JB o ss Secu rit y Pat ch es
Severit y
D escrip t io n
Critical
This rating is given to flaws that could be easily
exploited by a remote unauthenticated attacker
and lead to system compromise (arbitrary code
execution) without requiring user interaction.
These are the types of vulnerabilities that can be
exploited by worms. Flaws that require an
authenticated remote user, a local user, or an
unlikely configuration are not classed as critical
impact.
This rating is given to flaws that can easily
compromise the confidentiality, integrity, or
availability of resources. These are the types of
vulnerabilities that allow local users to gain
privileges, allow unauthenticated remote users
to view resources that should otherwise be
protected by authentication, allow authenticated
remote users to execute arbitrary code, or allow
local or remote users to cause a denial of
service.
Important
15
Severit y
D escrip t io n
Moderate
This rating is given to flaws that may be more
difficult to exploit but could still lead to some
compromise of the confidentiality, integrity, or
availability of resources, under certain
circumstances. These are the types of
vulnerabilities that could have had a critical
impact or important impact but are less easily
exploited based on a technical evaluation of the
flaw, or affect unlikely configurations.
This rating is given to all other issues that have
a security impact. These are the types of
vulnerabilities that are believed to require
unlikely circumstances to be able to be
exploited, or where a successful exploit would
give minimal consequences.
Low
The impact component of a CVSS v2 score is based on a combined assessment of three potential
impacts: Confidentiality (C), Integrity (I) and Availability (A). Each of these can be rated as None (N),
Partial (P) or Complete (C).
Because the JBoss server process runs as an unprivileged user and is isolated from the host
operating system, JBoss security flaws are only rated as having impacts of either None (N) or Partial
(P).
Examp le 2.1. C VSS v2 Imp act Sco re
The example below shows a CVSS v2 impact score, where exploiting the flaw would have no
impact on system confidentiality, partial impact on system integrity and complete impact on system
availability (that is, the system would become completely unavailable for any use, for example, via
a kernel crash).
C : N/I: P /A: C
Combined with the severity rating and the CVSS score, organizations can make informed decisions
on the risk each issue places on their unique environment and schedule upgrades accordingly.
For more information about CVSS2, please see: CVSS2 Guide.
Report a bug
16
⁠Chapt er 3. WS- Securit y
Chapter 3. WS-Security
3.1. WS-Securit y Overview
WS-Security standards allow policies to be applied to SOA for controlled service usage and
monitoring. WS-Security provides the means to secure your services beyond transport level
protocols such as HTTPS. Through a number of standards such as XML-Encryption, and headers
defined in the WS-Security standard, it allows you to:
Pass authentication tokens between services
Encrypt messages or parts of messages
Sign messages
Timestamp messages
WS-Security makes heavy use of public and private key cryptography. It is helpful to understand
these basics to really understand how to configure WS-Security. With public key cryptography, a
user has a pair of public and private keys. These are generated using a large prime number and a
key function. The keys are related mathematically, but cannot be derived from one another. With
these keys we can encrypt messages. For example, if Bob wants to send a message to Alice, he can
encrypt a message using her public key. Alice can then decrypt this message using her private key.
Only Alice can decrypt this message as she is the only one with the private key. Messages can also
be signed. This allows you to ensure the authenticity of the message. If Alice wants to send a
message to Bob, and Bob wants to be sure that it is from Alice, Alice can sign the message using her
private key. Bob can then verify that the message is from Alice by using her public key.
Report a bug
3.2. JBoss WS-Securit y Support
JBoss Web Services supports many real world scenarios requiring WS-Security functionalities. This
includes signature and encryption support through X509 certificates, authentication and
authorization through username tokens as well as all ws-security configurations covered by WSSecurityPolicy specification. The core of WS-Security functionalities is provided through the Apache
CXF engine. On top of that the JBossWS integration adds few configuration enhancements to
simplify the setup of WS-Security enabled endpoints.
Report a bug
3.3. Apache CXF WS-Securit y Implement at ion
Apache CXF features a WS-Security module that supports multiple configurations and is easily
extendible. The system is based on interceptors that delegate to Apache WSS4J for the low level
security operations. Interceptors can be configured in different ways, either through Spring
configuration files or directly using Apache CXF client API. For more details, refer to the Apache CXF
documentation.
Recent versions of Apache CXF introduced support for WS-Security Policy, which aims at moving
most of the security configuration into the service contract (through policies), so that clients can
easily be configured almost completely automatically from that. This way users do not need to
manually deal with configuring or installing the required interceptors. The Apache CXF WS-Policy
engine internally takes care of that.
17
Report a bug
3.3.1. WS-Securit y Policy Support
WS-SecurityPolicy describes the actions that are required to securely communicate with a service
advertised in a given WSD L contract. The WSD L bindings and operations reference WS-Policy
fragments with the security requirements to interact with the service. The WS-SecurityPolicy
specification allows for specifying things like asymmetric and symmetric keys, using transports
(https) for encryption, which parts or headers to encrypt or sign, whether to sign then encrypt or
encrypt then sign, whether to include timestamps, and whether to use derived keys.
Some mandatory configuration elements are not covered by WS-SecurityPolicy because they are not
meant to be public or part of the published endpoint contract. These include things such as keystore
locations, usernames and passwords. Apache CXF allows configuring these elements either through
Spring xml descriptors or using the client API or annotations. Below is the list of supported
configuration properties:
T ab le 3.1. Su p p o rt ed C o n f ig u rat io n Pro p ert ies
Pro p ert y
D escrip t io n
ws-security.username
The username used for UsernameToken policy
assertions.
The password used for UsernameToken policy
assertions. If not specified, the callback handler
is called.
The WSS4J security CallbackHandler that is
used to retrieve passwords for keystores and
UsernameTokens.
The properties file or object that contains the
WSS4J properties for configuring the signature
keystore and crypto objects.
The properties file or object that contains the
WSS4J properties for configuring the encryption
keystore and crypto objects.
The username or alias for the key in the
signature keystore. If not specified, it uses the
the default alias set in the properties file. If that is
also not set, and the keystore only contains a
single key, that key is used.
The username or alias for the key in the
encryption keystore. If not specified, it uses the
default alias set in the properties file. If that is
also not set, and the keystore only contains a
single key, that key is used. For the web service
provider, the useReqSigCert keyword can be
used to accept (encrypt to) any client whose
public key is in the service's truststore (defined
in ws-securi ty. encrypti o n. pro perti es.)
Instead of specifying the signature properties,
this can point to the full WSS4J Crypto object.
This can allow easier programmatic
configuration of the Crypto information.
ws-security.password
ws-security.callback-handler
ws-security.signature.properties
ws-security.encryption.properties
ws-security.signature.username
ws-security.encryption.username
ws-security.signature.crypto
18
Pro p ert y
D escrip t io n
ws-security.encryption.crypto
Instead of specifying the encryption properties,
this can point to the full WSS4J Crypto object.
This can allow easier programmatic
configuration of the Crypto information.
Here is an example of configuration using the client API:
Map<String, Object> ctx = ((BindingProvider)port).getRequestContext();
ctx.put("ws-security.encryption.properties", properties);
port.echoString("hello");
For additional configuration details, refer to the Apache CXF documentation.
Report a bug
3.3.2. JBossWS Configurat ion Addit ions
In order for removing the need of Spring on server side for setting up WS-Security configuration
properties not covered by policies, the JBossWS integration allows for getting those pieces of
information from a defined endpoint configuration. Endpoint configurations can include property
declarations and endpoint implementations can be associated with a given endpoint configuration
using the @EndpointConfig annotation.
< ?xml version="1.0" encoding="UTF-8"?>
< jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbosswsjaxws-config_4_0.xsd">
<endpoint-config>

<config-name>Custom WS-Security Endpoint</config-name>

<property-name>ws-security.signature.properties</property-name>

<property-value>bob.properties</property-value>

</property>

<property-name>ws-security.encryption.properties</property-name>

</property>

<property-name>ws-security.signature.username</property-name>

<property-value>bob</property-value>

</property>

<property-name>ws-security.encryption.username</property-name>

<property-value>alice</property-value>

</property>

<property-name>ws-security.callback-handler</property-name>

<propertyvalue>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCa
19
llback</property-value>

</property>
</endpoint-config>
< /jaxws-config>
i mport javax.jws.WebService;
i mport org.jboss.ws.api.annotation.EndpointConfig;

@ WebService

(

portName = "SecurityServicePort",

serviceName = "SecurityService",

wsdlLocation = "WEB-INF/wsdl/SecurityService.wsdl",

targetNamespace = "http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy",

endpointInterface =
"org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceIface"

)
@ EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml",
configName = "Custom WS-Security Endpoint")
p ublic class ServiceImpl implements ServiceIface

{

public String sayHello()

{

return "Secure Hello World!";

}

}
Report a bug
3.3.3. Apache CXF Annot at ions
The JBossWS configuration additions allow for a descriptor approach to the WS-Security Policy
engine configuration. If you prefer to provide the same information through an annotation approach,
you can leverage the Apache CXF @org.apache.cxf.annotations.EndpointProperties annotation:
@ WebService(

...

)
@ EndpointProperties(value = {

@ EndpointProperty(key = "ws-security.signature.properties", value =
"bob.properties"),

@ EndpointProperty(key = "ws-security.encryption.properties", value
= "bob.properties"),

@ EndpointProperty(key = "ws-security.signature.username", value =
"bob"),

@ EndpointProperty(key = "ws-security.encryption.username", value =
"alice"),

@ EndpointProperty(key = "ws-security.callback-handler", value =
"org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCallbac
k")

}
20
)
ublic class ServiceImpl implements ServiceIface {
p

...

}
Report a bug
3.4 . Enable WS-Securit y
Pro ced u re 3.1. En ab le WS- Secu rit y
1. D efine a Policy within your WSD L and reference it with a PolicyReference inside your
binding.
2. Configure your <soap.binding> with <securityAction>.
This is so that JBossWS-CXF knows which tokens to respect within incoming SOAP requests.
3. Include a WEB-INF/jbo ss-web. xml file in your application with a <security-domain>
specified.
This is so that JBossWS-CXF knows which modules to use for authentication and
rolemapping.
Report a bug
3.5. Sample WS-Securit y Configurat ions
SwitchYard provides the po l i cy-securi ty-wss-username quick start to give you an example.
Here are the pertinent sections:
MET A-INF/Wo rkServi ce. wsd l :
<binding name="WorkServiceBinding" type="tns:WorkService">
<wsp:PolicyReference URI="#WorkServicePolicy"/>
...
</binding>
<wsp:Policy wsu:Id="WorkServicePolicy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/wssx/ws-securitypolicy/200702">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://docs.oasisopen.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
21
MET A-INF/swi tchyard . xml :
<binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
<wsdl>META-INF/WorkService.wsdl</wsdl>
<contextPath>policy-security-wss-username</contextPath>
<securityAction>UsernameToken</securityAction>
</binding.soap>
WEB-INF/jbo ss-web. xml :
<jboss-web>
<security-domain>java:/jaas/other</security-domain>
</jboss-web>
With these in place, JBossWS-CXF will intercept incoming SOAP requests, extract the
UsernameToken, attempt to authenticate it against the LoginModule(s) configured in the application
server's " other" security domain, and provide any authorized roles. If successful, the request will be
handed over to SwitchYard, which can do further processing, including enforcing your own policies.
In the case of WS-Security, SwitchYard will not attempt a second clientAuthentication, but instead will
respect the outcome from JBossWS-CXF.
Note
If the original clientAuthentication fails, this is a " fail-fast" scenario, and the request will not be
channeled into SwitchYard.
Report a bug
3.6. Signat ure and Encrypt ion Support
To add the support for WS-Security Signature and Encryption, ensure the following:
Include the added requirements to the Policy in your WSD L. See Section 3.7, “ Sample Endpoint
Configurations” , Section 3.8, “ Sample Client Configurations” , and Section 3.9, “ Endpoint Serving
Multiple Clients” .
Add a CXF Interceptor which sets certain CXF security properties. See Section 3.10, “ Sample CXF
Interceptor Configurations” .
Report a bug
3.7. Sample Endpoint Configurat ions
An endpoint declares all the abstract methods that are exposed to the client. You can use endpoint
configurations to include property declarations. The endpoint implementations can be associated
with a given endpoint configuration using the @EndpointConfig annotation. The following steps
describe a sample endpoint configuration:
1. Create the web service endpoint using JAX-WS. Use a contract-first approach when using
WS-Security as the policies declared in the WSD L are parsed by the Apache CXF engine on
both server and client sides. Here is an example of WSD L contract enforcing signature and
encryption using X 509 certificates:
22
< ?xml version="1.0" encoding="UTF-8" standalone="yes"?>
< definitions targetNamespace="http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy" name="SecurityService"

xmlns:tns="http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns="http://schemas.xmlsoap.org/wsdl/"

xmlns:wsp="http://www.w3.org/ns/ws-policy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis200401-wss-wssecurity-utility-1.0.xsd"

xmlns:wsaws="http://www.w3.org/2005/08/addressing"

xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<types>

<xsd:schema>

<xsd:import namespace="http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy"
schemaLocation="SecurityService_schema1.xsd"/>

</xsd:schema>
</types>
<message name="sayHello">

</operation>
</portType>
<binding name="SecurityServicePortBinding"
type="tns:ServiceIface">

<wsp:PolicyReference
URI="#SecurityServiceSignThenEncryptPolicy"/>

<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>

<soap:operation soapAction=""/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>
</binding>
<service name="SecurityService">

<soap:address location="http://localhost:8080/jaxws-sampleswssePolicy-sign-encrypt"/>
23

</port>
</service>

<wsp:Policy wsu:Id="SecurityServiceSignThenEncryptPolicy"

<wsp:ExactlyOne>

<wsp:All>

<sp:AsymmetricBinding

<wsp:Policy>

<sp:InitiatorToken>

<wsp:Policy>

<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypoli
cy/IncludeToken/AlwaysToRecipient">

<wsp:Policy>

<sp:WssX509V1Token11/>

</wsp:Policy>

</sp:X509Token>

</wsp:Policy>

</sp:InitiatorToken>

<sp:RecipientToken>

<wsp:Policy>

<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypoli
cy/IncludeToken/Never">

<wsp:Policy>

<sp:WssX509V1Token11/>

</wsp:Policy>

</sp:X509Token>

</wsp:Policy>

</sp:RecipientToken>

<sp:AlgorithmSuite>

<wsp:Policy>

<sp-cxf:Basic128GCM xmlns:spcxf="http://cxf.apache.org/custom/security-policy"/>

</wsp:Policy>

</sp:AlgorithmSuite>

<sp:Layout>

<wsp:Policy>

<sp:Lax/>

</wsp:Policy>

</sp:Layout>

<sp:IncludeTimestamp/>

<sp:EncryptSignature/>

<sp:OnlySignEntireHeadersAndBody/>

<sp:SignBeforeEncrypting/>

</wsp:Policy>

</sp:AsymmetricBinding>

<sp:SignedParts

<sp:Body/>

</sp:SignedParts>

<sp:EncryptedParts

<sp:Body/>
24

</sp:EncryptedParts>
<sp:Wss10

<wsp:Policy>

<sp:MustSupportRefIssuerSerial/>

</wsp:Policy>

</sp:Wss10>

</wsp:All>

</wsp:ExactlyOne>
</wsp:Policy>
< /definitions>

You can generate the service endpoint using the wsco n su me tool and then use a
@EndpointConfig annotation as shown below:
p ackage org.jboss.test.ws.jaxws.samples.wsse.policy.basic;

i mport javax.jws.WebService;
i mport org.jboss.ws.api.annotation.EndpointConfig;

@ WebService

(

portName = "SecurityServicePort",

serviceName = "SecurityService",

wsdlLocation = "WEB-INF/wsdl/SecurityService.wsdl",

targetNamespace = "http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy",

endpointInterface =
"org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceIface"

)
@ EndpointConfig(configFile = "WEB-INF/jaxws-endpoint-config.xml",
configName = "Custom WS-Security Endpoint")
p ublic class ServiceImpl implements ServiceIface

{

public String sayHello()

{

return "Secure Hello World!";

}

}
2. Use the referenced jaxws-end po i nt-co nfi g . xml descriptor to provide a custom
endpoint configuration with the required server side configuration properties as shown
below. This tells the engine which certificate or key to use for signature, signature verification,
encryption, and decryption.
< jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0
schema/jbossws-jaxws-config_4_0.xsd">
25

<endpoint-config>
<config-name>Custom WS-Security Endpoint</config-name>

<property-name>ws-security.signature.properties</propertyname>

</property>

<property-name>ws-security.encryption.properties</propertyname>

</property>

<property-name>ws-security.signature.username</property-name>

<property-value>bob</property-value>

</property>

<property-name>ws-security.encryption.username</propertyname>

<property-value>alice</property-value>

</property>

<property-name>ws-security.callback-handler</property-name>

<propertyvalue>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePass
wordCallback</property-value>

</property>
</endpoint-config>
< /jaxws-config>

Here,
The bo b. pro perti es configuration file includes the WSS4J Crypto properties which in
turn links to the keystore file, type, alias, and password for accessing it. For example:
o rg.apache.ws.security.crypto.provider=org.apache.ws.security.co
mponents.crypto.Merlin
o rg.apache.ws.security.crypto.merlin.keystore.type=jks
o rg.apache.ws.security.crypto.merlin.keystore.password=password
o rg.apache.ws.security.crypto.merlin.keystore.alias=bob
o rg.apache.ws.security.crypto.merlin.keystore.file=bob.jks
The callback handler enables Apache CXF to access the keystore. For example:
p ackage org.jboss.test.ws.jaxws.samples.wsse.policy.basic;

i mport
i mport
i mport
i mport
i mport
i mport
26
java.io.IOException;
java.util.HashMap;
java.util.Map;
javax.security.auth.callback.Callback;
javax.security.auth.callback.CallbackHandler;
javax.security.auth.callback.UnsupportedCallbackException;
i mport org.apache.ws.security.WSPasswordCallback;

p ublic class KeystorePasswordCallback implements CallbackHandler
{

private Map<String, String> passwords = new HashMap<String,
String>();

public KeystorePasswordCallback() {
passwords.put("alice", "password");
passwords.put("bob", "password");
}

/**

* It attempts to get the password from the private

* alias/passwords map.

*/

public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {

for (int i = 0; i < callbacks.length; i++) {

WSPasswordCallback pc =
(WSPasswordCallback)callbacks[i];

String pass = passwords.get(pc.getIdentifier());
if (pass != null) {
pc.setPassword(pass);
return;
}

}

/**
* Add an alias/password pair to the callback mechanism.
*/
public void setAliasPassword(String alias, String password) {
passwords.put(alias, password);
}

}
3. Assuming the bo b. jks keystore is properly generated and contains the server Bob's full key
as well as the client Alice's public key, you can proceed to packaging the endpoint. Here is
the expected content:
/dati/jbossws/stack/cxf/trunk $ jar -tvf ./modules/testsuite/cxftests/target/test-libs/jaxws-samples-wsse-policy-sign-encrypt.war
0 Thu Jun 16 18:50:48 CEST 2011 META-INF/
140 Thu Jun 16 18:50:46 CEST 2011 META-INF/MANIFEST.MF
0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/
586 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/web.xml
0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/
0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/
0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/
0 Thu Jun 16 18:50:48 CEST 2011 WEB-INF/classes/org/jboss/test/
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/
0 Thu Jun 16 18:50:48 CEST 2011 WEB-
27
INF/classes/org/jboss/test/ws/jaxws/
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/
1687 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/Keysto
rePasswordCallback.class
383 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/Servic
eIface.class
1070 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/basic/Servic
eImpl.class
0 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/
705 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/SayHel
lo.class
1069 Thu Jun 16 18:50:48 CEST 2011 WEBINF/classes/org/jboss/test/ws/jaxws/samples/wsse/policy/jaxws/SayHel
loResponse.class
1225 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/jaxws-endpointconfig.xml
0 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/wsdl/
4086 Thu Jun 16 18:50:44 CEST 2011 WEBINF/wsdl/SecurityService.wsdl
653 Thu Jun 16 18:50:44 CEST 2011 WEBINF/wsdl/SecurityService_schema1.xsd
1820 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/classes/bob.jks
311 Thu Jun 16 18:50:44 CEST 2011 WEB-INF/classes/bob.properties
Here, the jaxws classes generated by the tools and a basic web.xml referencing the endpoint
bean are also included:
< web-app

version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<servlet-name>TestService</servlet-name>

<servletclass>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceImpl<
/servlet-class>

</servlet>

<servlet-mapping>
28

<servlet-name>TestService</servlet-name>
<url-pattern>/*</url-pattern>

</servlet-mapping>
< /web-app>

Note
If you are deploying the endpoint archive to JBoss Application Server 7, add a
dependency to o rg . apache. ws. securi ty module in the MANIFEST . MF file:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 17.0-b16 (Sun Microsystems Inc.)
Dependencies: org.apache.ws.security
Report a bug
3.8. Sample Client Configurat ions
On the client side, use the wsco n su me tool to consume the published WSD L and then invoke the
endpoint as a standard JAX-WS one as shown below:
QName serviceName = new QName("http://www.jboss.org/jbossws/wsextensions/wssecuritypolicy", "SecurityService");
URL wsdlURL = new URL(serviceURL + "?wsdl");
Service service = Service.create(wsdlURL, serviceName);
ServiceIface proxy = (ServiceIface)service.getPort(ServiceIface.class);
((BindingProvider)proxy).getRequestContext().put(SecurityConstants.CALLBA
CK_HANDLER, new KeystorePasswordCallback());
((BindingProvider)proxy).getRequestContext().put(SecurityConstants.SIGNA
TURE_PROPERTIES,
Thread.currentThread().getContextClassLoader().getResource("METAINF/alice.properties"));
((BindingProvider)proxy).getRequestContext().put(SecurityConstants.ENCRY
PT_PROPERTIES,
Thread.currentThread().getContextClassLoader().getResource("METAINF/alice.properties"));
((BindingProvider)proxy).getRequestContext().put(SecurityConstants.SIGNA
TURE_USERNAME, "alice");
((BindingProvider)proxy).getRequestContext().put(SecurityConstants.ENCRY
PT_USERNAME, "bob");
proxy.sayHello();
The WS-Security properties are set in the request context. Here, the KeystorePasswordCallback
is same as that on the server side. The al i ce. pro perti es file is the client side equivalent of the
server side bo b. pro perti es file and references the al i ce. jks keystore file, which has been
populated with client Alice's full key as well as server Bob's public key:
29
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.
crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.alias=alice
org.apache.ws.security.crypto.merlin.keystore.file=META-INF/alice.jks
The Apache CXF WS-Policy engine consumes the security requirements in the contract and ensures
that a valid secure communication is in place for interacting with the server endpoint.
Report a bug
3.9. Endpoint Serving Mult iple Client s
n the endpoint and client configuration examples, the server side configuration implies that the
endpoint is configured for serving a given client which a service agreement is established for. In real
world scenarios, a server should be able to decrypt and encrypt messages coming from and being
sent to multiple clients. Apache CXF supports that through the useReqSigCert value for the wssecurity.encryption.username configuration parameter. The referenced server side keystore
then needs to contain the public key of all the clients that are expected to be served.
Report a bug
3.10. Sample CXF Int ercept or Configurat ions
For adding a CXF Interceptor, perform the following configuration settings:
MET A-INF/swi tchyard . xml
< binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
<wsdl>META-INF/WorkService.wsdl</wsdl>
<contextPath>policy-security-wss-username</contextPath>
<inInterceptors>

<interceptor class="com.example.MyInterceptor"/>
</inInterceptors>
< /binding.soap>
co m/exampl e/MyIntercepto r. java
p ublic class MyInterceptor extends WSS4JInterceptor {
private static final PROPS;
static {

Map<String,String> props = new HashMap<String,String>();

props.put("action", "Signature Encryption");

props.put("signaturePropFile", "META-INF/bob.properties");

props.put("decryptionPropFile", "META-INF/bob.properties");

props.put("passwordCallbackClass",
"com.example.MyCallbackHandler");

PROPS = props;
30

}
public MyInterceptor() {
super(PROPS);
}

}
MET A-INF/bo b. pro perti es
org.apache.ws.security.crypto.provider=org.apache.ws.security.componen
ts.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.alias=bob
org.apache.ws.security.crypto.merlin.file=META-INF/bob.jks
Report a bug
31
Chapter 4. S-RAMP Security
4 .1. S-RAMP Browser
S-RAMP comes with a user interface that allows you to browse all of the artifacts in the S-RAMP
repository. This UI is capable of viewing and manipulating all S-RAMP artifacts in a very generic
way, supporting all aspects of the S-RAMP specification such as properties, classifiers, and
relationships.
The browser is a web based application built using Google Web Toolkit (GWT) and Errai projects,
and is compatible with all modern web browsers. Additionally, it is capable of scaling the interface
down to a size that is useful on a smart phone.
Report a bug
4 .1.1. S-RAMP Browser Aut hent icat ion
The installer handles the following S-RAMP Browser Authentication configurations automatically:
Security domain configuration (for both S-RAMP Browser and S-RAMP Server)
Web based single-sign-on configuration
ID P web application configuration
Managing Admin user
Report a bug
4 .1.2. S-RAMP Browser Aut horiz at ion
The S-RAMP Browser UI does not support any sort of fine grained authorization. You only need to
have the following role in order to log in and use the UI:
overlorduser
Report a bug
4 .2. S-RAMP Server
The S-RAMP implementation is a fully compliant reference implementation of the S-RAMP
specification. It provides a Java based client library that you can use to integrate your own
applications with an S-RAMP compliant server. The server implementation is a conventional Java
web application (WAR). The following technologies are used to provide the various components that
make up the server implementation:
JCR (ModeShape): Used as the persistence engine, where all S-RAMP data is stored. Artifacts and
ontologies are both stored as nodes in a JCR tree. All S-RAMP queries are mapped to JCRSQL2
queries for processing by the JCR API. The ModeShape JCR implementation is used by default.
However, the persistence layer is pluggable allowing alternative providers to be implemented in
the future.
32
⁠Chapt er 4 . S- RAMP Securit y
JAX-RS (RESTEasy): Used to provide the S-RAMP Atom based REST API. The S-RAMP
specification documents an Atom based REST API that implementations should make available.
The S-RAMP implementation uses JAX-RS (specifically RESTEasy) to expose all of the REST
endpoints defined by the specification.
JAXB: Used to expose a Java data model based on the S-RAMP data structures defined by the
specification (S-RAMP XSD schemas).
For more information on underlying run-time, refer JBoss Enterprise Application Platform 6.1 Security
Guide.
Report a bug
4 .2.1. S-RAMP Server Aut horiz at ion
When accessing the S-RAMP Atom API, the authenticated user must have certain roles. As the
implementation leverages ModeShape as its persistence store by default, the authenticated user must
have the following JAAS role, which is required by ModeShape:
admin.sramp
Additionally, the S-RAMP Atom API web application requires the user to have the following role:
overlorduser
Report a bug
33
Chapter 5. Policy
5.1. About Policy
Policy enables you to verify the runtime behavior of a service in a declarative manner, free of the
service implementation and binding details. For example, if you require a service to always
participate in a global transaction only, you can add logic to your service implementation which
checks the current transaction state, associates with an active global transaction, and handles error
cases. Also, ensure that the gateway used to expose the service is transactional and that it
propagates the transaction to the service implementation.
The SwitchYard runtime reads these policy definitions during deployment and enforces them on a
per-message basis as services are invoked.
Report a bug
5.2. Configuring Policy
The Policy definition is comprised of two aspects:
Policy that the service provider requires
Policy support that the service consumer provides
You can define the policy that a service requires by annotating the service's configuration in the
SwitchYard application descriptor. You can also define how a service is consumed through a
gateway binding, which effectively determines how the policy requirements are satisfied or provided.
The SwitchYard runtime takes care of determining whether the consumer satisfies the policy
requirements by evaluating the configuration of the application and the runtime state of the
messages exchanged between the consumer and provider. Here is an example configuration:
<composite name="policy-transaction">
<service name="WorkService" promote="WorkService">
<camel:binding.camel configURI="jms://policyQSTransacted?
connectionFactory=%23JmsXA& transactionManager=%23jtaTransactionManager& t
ransacted=true"/>
<camel:binding.camel configURI="jms://policyQSNonTransacted?
connectionFactory=#ConnectionFactory"/>
</service>
<component name="WorkService">
<implementation.bean
class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean
" requires="managedTransaction.Global"/>
<service name="WorkService" requires="propagatesTransaction">
<interface.java
interface="org.switchyard.quickstarts.demo.policy.transaction.WorkService
"/>
</service>
<reference name="TaskAService" requires="propagatesTransaction">
<interface.java
interface="org.switchyard.quickstarts.demo.policy.transaction.TaskAServic
e"/>
</reference>
</component>
</composite>
34
⁠Chapt er 5. Policy
Report a bug
5.3. Int eract ion Policy
In SwitchYard, the component service and component reference both are marked by policies using
requires attribute. You can use the Interaction policy on component service and component
reference and is not allowed to be marked on component implementation. This policy enables you to
manage the communication between the service provider and consumer.
Report a bug
5.4 . Implement at ion Policy
In SwitchYard, the component service and component reference both are marked by policies using
requires attribute. You can use the Implementation policy on component implementation and is not
allowed to be marked on component service nor component reference.
Report a bug
5.5. T ransact ion Policy
Transaction Policy defines implementation and interaction policies that relate to transactional quality
of service in components and their interactions. The transaction policies are specified as intents
which represent the transaction quality of service behavior offered by specific component
implementations or bindings.
Report a bug
5.5.1. T ransact ion Int eract ion Policy
You can specify the Transaction Interaction Policy by using a component service or component
reference definition's requires attribute. Here is an example:
<service name="WorkService" requires="propagatesTransaction">
Valid values for the Transaction Interaction Policy intents are:
propagatesTransaction: Indicates that a global transaction is required when a service is
invoked. If no transaction is present, the SwitchYard generates an error at runtime.
suspendsTransaction: Indicates that if a transaction exists, the SwitchYard runtime suspends
it before the service implementation is invoked and resumes it after the service invocation. This
setting allows you to separate a gateway binding's transactional context from the transactional
context of the service implementation.
You can attach the mutually exclusive propagatesTransaction and suspendsTransaction
intents either to an interface or explicitly to a service and reference XML element in order to describe
how any client transaction context is made available and used by the target service component.
35
Fig u re 5.1. T ran sact io n In t eract io n Po licy
Report a bug
5.5.2. T ransact ion Implement at ion Policy
You can specify the Implementation Interaction Policy by using a component service or component
reference definition's requires attribute. Here is an example:
<implementation.bean
class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean
" requires="managedTransaction.Global">
Valid values for Transaction Implementation Policy intents are:
managedTransaction.Global: Indicates that this service implementation runs under a global
transaction. If no transaction is present, the SwitchYard runtime creates a new JTA transaction
before the execution. The SwitchYard runtime commits this newly created transaction at the end of
service execution.
managedTransaction.Local: Indicates that this service implementation runs under a local
transaction. If a transaction exists, the SwitchYard runtime suspends it. SwitchYard always
creates a new JTA transaction before execution. The SwitchYard runtime commits this newly
created transaction and resumes the suspended transcation after the service invocation.
Note
As the local transaction does not propagate its transaction through the reference, you must
mark all of the component reference as suspendsTransaction. If not, the SwitchYard
runtime generates an error.
noManagedTransaction: Indicates that this service implementation does not run under any
managed transaction. If a transaction exists, the SwitchYard runtime suspends it before the
service implementation is invoked and resumes it after the service invocation.
You can use the mutually exclusive managedTransaction and noManagedTransaction intents
to describe the transactional environment required by a service component.
Sco p e o f Su p p o rt
Currently, the following gateways are transaction aware:
Camel JMS Gateway (binding.jms)
36
Camel JPA Gateway (binding.jpa)
Camel SQL Gateway (binding.sql)
JCA Gateway (binding.jca)
SCA Gateway (binding.sca)
Note
BPM service (implementation.bpm) always need a JTA transaction if the persistence is
enabled. It synchronizes with incoming transaction if exists, otherwise it begins a new JTA
Transaction and commit/rollback by itself.
Note
If your application has multiple camel-jms bindings which are bound to the same JMS
provider, you need to define distinct connection factory for each binding to get Transaction
Policy working. otherwise, transaction can't be suspended as expected. Similarly, distinct xadatasource is needed to get Transaction Policy working on camel-jpa and camel-sql.
(https://issues.jboss.org/browse/SWITCHYARD -1285)
Fig u re 5.2. T ran sact io n Imp lemen t at io n Po licy
Report a bug
5.6. Securit y Policy
SwitchYard services can be secured by specifying a list of security policies that are required for that
service and configuring the security processing details for the services within a domain.
37
Note
The security manager gets enabled with additional security policies if you select the Run-Time
Governance component during installation. Following are the security policies included in
FSW:
security.policy- It defines a JVM level permitAll policy.
kie.policy- It is used by Rule-based services.
rtgov.policy- It is used for the Run-Time Governance REST API.
Note
Support for security policy is limited to bean services (implementation.bean), SOAP endpoints
via the SOAP gateway (binding.soap), and HTTP endpoints via the HTTP gateway
(binding.http).
Report a bug
5.6.1. Securit y Int eract ion Policy
The Security Interaction Policy is defined using the requires attribute of a component service
definition.
<service name="WorkService" requires="authorization clientAuthentication
confidentiality">
Valid values for Security Interaction policy are:
clientAuthentication: indicates that the client has been authenticated when a service is invoked. If
the associated authenticated user principal is not available, SwitchYard runtime generates an
error.
confidentiality: indicates that the request has been made over a secure channel. When a SOAP
request is made over SSL and its confidentiality is not verified, SwitchYard runtime generates an
error,
Fig u re 5.3. Secu rit y In t eract io n Po licy
38
Report a bug
5.6.2. Securit y Implement at ion Policy
Security Implementation Policy is specified using the requires attribute of a component
implementation definition.
Valid values for Security Implementation policy are:
authorization: indicates that the the client is authorized to invoke the service. If the associated
authenticated subject does not have an allowed role, SwitchYard runtime generates an error.
Fig u re 5.4 . Secu rit y Imp lemen t at io n Po licy
Report a bug
5.6.3. Set t ing Securit y Policy
You can define the Security Policy in the following ways:
Edit the SwitchYard application descriptor (swi tchyard . xml ) and add the requires attribute
to a service definition.
Use the @Requires attribute in your service implementation to declare security policy for the
service. When the application project is built, the SwitchYard application finds @Requires
annotations and automatically generates the required configuration.
Report a bug
5.6.4 . Securit y Processing
When the container does not automatically provide certain security policies, the SwitchYard
application can be configured to process security credentials extracted from the binding-specific
data, then provide certain security policies itself (like clientAuthentication). All services within a
domain share the same security configuration, which is specified in the swi tchyard . xml .
<switchyard>
<domain>
moduleName"="jaas-domain-name" rolesAllowed="users, administrators"
runAs="leaders">
<properties>
<property name="property-name" value="property-value"/>
39
</properties>
</security>
</domain>
</switchyard>
Note
Support for security policy is limited to bean services (implementation.bean), SOAP endpoints
via the SOAP gateway (binding.soap), and HTTP endpoints via the HTTP gateway
(binding.http).
Report a bug
40
Revision Hist ory
Revision History
R evisio n 6 .0.0- 21
T h u O ct 16 2014
N ilam Sh en d ye
Built from Content Specification: 22590, Revision: 716892 by nshendye
41