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 [email protected] m David Le Sage Red Hat Engineering Co ntent Services [email protected] m Anshu Mahajan [email protected] 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 JBoss Fuse Service Works 6 Securit y G uide 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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> <security callbackHandler="callback-handler-class-name" moduleName="jaas-domain-name" rolesAllowed="users, administrators" runAs="leaders"> <properties> <property name="property-name" value="property-value"/> 8 Chapt er 1 . Swit chYard Securit y </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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 1 . Swit chYard Securit y 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 This quickstart exposes a bean service through a soap binding. Confidentiality is provided via SSL, and client authentication via an X509 Certificate. See the Readme.md file for details. p o licy- secu rit y- saml This quickstart exposes a bean service through a soap binding. Confidentiality is provided 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 This quickstart exposes a bean service through a soap binding. Confidentiality is provided 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 3. WS- Securit y 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> <property-name>ws-security.signature.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.encryption.properties</property-name> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.signature.username</property-name> <property-value>bob</property-value> </property> <property> <property-name>ws-security.encryption.username</property-name> <property-value>alice</property-value> </property> <property> <property-name>ws-security.callback-handler</property-name> <propertyvalue>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.KeystorePasswordCa 19 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 3. WS- Securit y ) 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 3. WS- Securit y < ?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"> <part name="parameters" element="tns:sayHello"/> </message> <message name="sayHelloResponse"> <part name="parameters" element="tns:sayHelloResponse"/> </message> <portType name="ServiceIface"> <operation name="sayHello"> <input message="tns:sayHello"/> <output message="tns:sayHelloResponse"/> </operation> </portType> <binding name="SecurityServicePortBinding" type="tns:ServiceIface"> <wsp:PolicyReference URI="#SecurityServiceSignThenEncryptPolicy"/> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <operation name="sayHello"> <soap:operation soapAction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="SecurityService"> <port name="SecurityServicePort" binding="tns:SecurityServicePortBinding"> <soap:address location="http://localhost:8080/jaxws-sampleswssePolicy-sign-encrypt"/> 23 Red Hat JBoss Fuse Service Works 6 Securit y G uide </port> </service> <wsp:Policy wsu:Id="SecurityServiceSignThenEncryptPolicy" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <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 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> </sp:SignedParts> <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> 24 Chapt er 3. WS- Securit y </sp:EncryptedParts> <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <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. < ?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/jbossws-jaxws-config_4_0.xsd"> 25 Red Hat JBoss Fuse Service Works 6 Securit y G uide <endpoint-config> <config-name>Custom WS-Security Endpoint</config-name> <property> <property-name>ws-security.signature.properties</propertyname> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.encryption.properties</propertyname> <property-value>bob.properties</property-value> </property> <property> <property-name>ws-security.signature.username</property-name> <property-value>bob</property-value> </property> <property> <property-name>ws-security.encryption.username</propertyname> <property-value>alice</property-value> </property> <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; Chapt er 3. WS- Securit y 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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: < ?xml version="1.0" encoding="UTF-8"?> < web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> <servlet> <servlet-name>TestService</servlet-name> <servletclass>org.jboss.test.ws.jaxws.samples.wsse.policy.basic.ServiceImpl< /servlet-class> </servlet> <servlet-mapping> 28 Chapt er 3. WS- Securit y <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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 3. WS- Securit y } 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 5. Policy 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 Red Hat JBoss Fuse Service Works 6 Securit y G uide 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 Chapt er 5. Policy 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> <security callbackHandler="callback-handler-class-name" moduleName"="jaas-domain-name" rolesAllowed="users, administrators" runAs="leaders"> <properties> <property name="property-name" value="property-value"/> 39 Red Hat JBoss Fuse Service Works 6 Securit y G uide </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
© Copyright 2024