Latest Activity

WADL and Swagger United in Apache CXF

Sergey Beryozkin - Fri, 11/20/2015 - 18:33
Who could've thought that Swagger and WADL can be real friends ?
Both Swagger and WADL are about describing REST APIs and while the former has a definite momentum, the latter has proved to be very capable and helpful to JAX-RS users.

The important thing is that we have users who submit WADL documents  to the runtime or build time code generators which is all working fine. We also have Swagger users who use cool Swagger features and being happy with a nice UI being generated. And WADL users, while being happy with WADL (which IMHO is indeed a very capable language for describing schema rich XML but with some extensions - even JSON - services) would like to use Swagger to introspect the code generated by WADL processors and have a nice API UI.

So my colleague Andrei and  Francesco, Apache Syncope maestro, have driven the work about enhancing a WADL generator to set WADL documentation fragments as Java Docs in the generated sources and then having CXF Swagger features being very smart about enhancing Swagger JSON payloads with these Java Docs, with Francesco doing some magic there. I should also mention Andriy Redko doing some work earlier on directly with Swagger for it to better support JAX-RS annotations and initiating the CXF Swagger project and Aki Yoshida doing a lot of Swagger2 work next.

So here you go, WADL and Swagger United in Apache CXF.

IMHO this project has been a perfect example of the power of the Open Source collaboration with the contributors from different teams working effectively on this project.


Categories: Sergey Beryozkin

HTrace your Apache CXF Service flows

Sergey Beryozkin - Fri, 11/20/2015 - 18:10
Andriy Redko keeps pushing CXF to the next level with adding new features nearly every few weeks :-).

One of his latest projects has been to do with wiring Apache HTrace into CXF such that CXF users can HTrace calls starting from CXF clients going to CXF servers and then to such HTrace aware containers as HBase  and using the collectors like Zipkin.

I'm looking forward to Andriy talking in detail about it on his blog and at the conferences, but in meantime you can check the documentation. Note that it works not only for JAX-RS but for JAX-WS too: if we can have a new feature working with both frontends then you know it will be done. The demo is here.

Give it a try and stay on top of the web services game :-)
Enjoy !



 
Categories: Sergey Beryozkin

JAX-RS 2.1 specification work has started

Sergey Beryozkin - Fri, 11/20/2015 - 17:51
JAX-RS 2.1 specification work has finally started after a rather quiet year and this is a good news for JAX-RS users at large and CXF JAX-RS users in particular.
JAX-RS 2.1 is entirely Java 8 based and a number of new enhancements are on the way. I was concerned earlier on that having a Java 8 will slow down the adoption but I think now the spec leads were right, Java 8 is so rich and JAX-RS needs to be open to accepting the latest Java features - ultimately this is what will excite the users.

The main new features list is: support for Server-Sent Events (something CXF users will enjoy experimenting with while also keeping in mind CXF has some great WebSocket support done by Aki), enhanced NIO support and introducing a reactive mode into Client API.

I've already mentioned before that JAX-RS 2.0 AsyncResponse API is IMHO very impressive as it makes a fairly complex task of dealing with suspended invocations becoming rather trivial to deal with. Marek and Santiago are doing it again with the new 2.1 proposals. Of course there will be some minor disagreements here and there but overall I'm very positive about this new JAX-RS project.


We now have a CXF Java 8 master branch to support the future JAX-RS 2.1 features but having a Java 8 trunk is great for all of the CXF community.

What is really good is that there appears to be no obvious end to the new requirements coming into the JAX-RS space. The HTTP services space is wide open, with the new ideas generated around the security, faster processing, etc, and it all will be eventually available as future JAX-RS features. I'm confident JAX-RS 3.0 will be coming in due time too.


Categories: Sergey Beryozkin

New security advisory for Apache CXF

Colm O hEigeartaigh - Mon, 11/16/2015 - 13:28
A new security advisory has been released for Apache CXF, which is fixed in the 3.1.3, 3.0.7 and 2.7.18 releases.
  • CVE-2015-5253: Apache CXF SAML SSO processing is vulnerable to a wrapping attack
Apache CXF supports the SAML SSO protocol with JAX-RS web service endpoints. It is possible for a malicious user to construct a SAML Response (the response from the SAML SSO IdP to the endpoint) via a so-called "wrapping attack", to allow that user to log in instead of the authenticated user associated with the signed SAML Assertion.

Please see the Apache CXF security advisories page for more information.
Categories: Colm O hEigeartaigh

Testing Kerberos with Web Services using Apache Kerby

Colm O hEigeartaigh - Wed, 11/11/2015 - 13:13
The previous blog post described how to use Apache Directory to easily create a KDC via Java annotations for kerberos integration testing. In this post, we will look at an alternative way of setting up a KDC for integration testing using Apache Kerby.

Apache Kerby is a new subproject of Apache Directory that aims to provide a complete Kerberos solution in Java. Version 1.0.0-RC1 has recently been released and is available for testing. Apache Kerby consists of both a KDC as well as a client API, that is completely independent of the GSS API that comes with Java. A key selling point of Apache Kerby is that it is very easy and fast to setup and deploy a KDC. It is possible to set up a KDC completely in code, without having to edit any configuration files or configure any system properties.

Let's see how this is done by looking at a project I created on github:
  • cxf-kerberos-kerby: This project contains a number of tests that show how to use Kerberos with Apache CXF, where the KDC used in the tests is based on Apache Kerby.
The KDC is launched in the test-code, and is pretty much as straightfoward as the following code snippet:

The first block of code configures the host, realm, transports and ports, while the second creates the client, service and TGT principals that are used in the tests. No configuration files required! As well as showing how to use Apache CXF to authenticate using both Kerberos and Spnego for a JAX-WS service, the AuthenticationTest also includes unit tests for getting a service ticket from the Kerby KDC using the Java GSS API as well as the Kerby client API. Using the Kerby client API is as simple as this:


Have fun playing around with Apache Kerby and please join and contribute to the project if you are interested!
Categories: Colm O hEigeartaigh

Testing Kerberos with Web Services using Apache Directory

Colm O hEigeartaigh - Mon, 10/26/2015 - 12:59
Apache CXF supports Kerberos for web services both via the Kerberos Token Profile of WS-Security, where the kerberos ticket is conveyed as a BinarySecurityToken in the security header of the client request, and over HTTP via the Negotiate authentication scheme. If you are developing kerberos-enabled web services using a framework like Apache CXF, a natural question to ask is how to set up a Kerberos KDC to test your web services prior to deployment. This is the first of two blog posts that shows two different ways to easily set up a KDC using open source projects for kerberos integration testing.

At ApacheCon EU 2014 in Budapest, I attended a great talk by Emmanuel Lécharny entitled "Testing LDAP Implementations". The talk covered how the Apache Directory project can be used to easily deploy Kerberos and LDAP servers in your test-code via annotations. This was music to my ears, as I had written a bunch of tests in Apache CXF for both LDAP and kerberos that were not run as part of the normal build, as they required a local KDC to run successfully. After this talk I got involved in the Apache Directory project, and converted the tests in Apache CXF to use Apache Directory instead, so they could be run as part of the normal build cycle. I also made some small improvements which I'll describe as part of this post.

I've created a project in github that shows how to use Apache Directory to set up a KDC, and how to use Apache CXF to authenticate to a web service using Kerberos, for both JAX-RS and JAX-WS:
  • cxf-kerberos: This project contains a number of tests that show how to use Kerberos with Apache CXF.
Both test-cases use an annotation to load a kerberos.ldif file, containing the information required to set up Kerberos principals in the KDC for testing:


 Another annotation sets up the Directory Service:

Finally, an annotation adds a KDC server:

The "KRB" protocol was added as part of DIRSERVER-2031 in the 2.0.0-M20 release. Previously, you could specify either "TCP" or "UDP" for the protocol attribute when testing Kerberos. However, this meant that they could not share the same port. The "KRB" protocol generates both TCP and UDP transports on the port provided, or otherwise on a random port. Previously, the random port generation was not working, as it always defaulted to 1024. Random port generation is an essential feature for testing as part of a build cycle, as hard-coded ports tend to cause problems on continuous integration platforms. Using a random port also means that the krb5.conf file used by the CXF clients must be read in, and the random port substituted into the file before writing it out again, as otherwise the clients would have no way of knowing the port the KDC was running on.
Categories: Colm O hEigeartaigh

A certificate revocation security vulnerability in Java

Colm O hEigeartaigh - Fri, 10/23/2015 - 12:04
A few days ago, Oracle released a Critical Patch Update containing fixes for various security vulnerabilities. In particular, the update contained fixes for 25 security vulnerabilities in Java itself. One of them, CVE-2015-4868, was discovered by me and duly disclosed to Oracle earlier this year. This issue has now been fixed in this Critical Patch Update (and included in Java 1.8.0_65), and so I am free to describe it.

1) Background

I first noticed this issue in the context of signature validation of SOAP web service requests. A signed SOAP request involves using XML Signature to sign some part of the request, where the resulting Signature structure is inserted into the security header of the request. The Signature contains a KeyInfo Element, which references the (public) key to use to validate the request. The recipient must resolve the appropriate public key, establish trust in it, and use it to validate the signature.

A common use-case is when the certificate used to validate the signature is included directly in the request, by BASE-64 encoding it in the security header. Optionally, the full certificate chain can be included instead. The recipient must take the certificates and establish a trust chain using a CA certificate stored in a local truststore, which is then validated.

However, what if the signing certificate has been revoked by the issuing CA? In this case, we can specify a Certificate Revocation List, and include it as part of the validation of the trust chain.

2) The vulnerability

Now to the vulnerability. Under the more usual use-case of just including the signing certificate in the security header, and establishing a trust-chain using a local truststore and CRL file, everything was working fine. Namely, if the signing certificate was trusted, but revoked, then the CertPath validation failed. However, if the issuing certificate of the signing certificate was also included in the security header, then CRL validation was not failing! This vulnerability exists in a range of JDK 8 versions prior to 1.8.0_65. It does not exist prior to JDK 8.

To see how this works using the Java CertPathValidator API, I created a simple maven-based unit test in github:
  • java.crls - A testcase that show how to include a CRL when validating the certificate path of a certificate.
The test has a JUnit failure assertion that asserts that the CertPathValidator validation should fail (as the signing certificate has been revoked). However, this failure assertion is not met when run locally with Java 1.8.0_51. With a Java version post-1.8.0_65 the failure assertion is met, and the test passes.
Categories: Colm O hEigeartaigh

[OT] Apache CXF: Nothing Else Matters !

Sergey Beryozkin - Fri, 10/09/2015 - 18:40
One can ask, do web services still matter in the today's world of emerging technologies such as Cloud and Big Data ?

Of course they do still matter. Take Big Data. The important thing to realize is as far as a remote client interacting with your HTTP server which internally initiates BigData flows is concerned it is still a client and HTTP server only - the client submits the data and gets the response it needs - the mechanism used to produce this response is, and has to be, completely opaque to the remote client, nothing unusual here, simply a proper service design leaking no implementation details to the client. In some cases one may not want to link BigData response streams to remote clients but in other cases it may make a perfect sense.

So yes, the web services do still matter because one still needs a production-quality, secure, flexible HTTP layer between the remote clients and internal data systems.

In fact, if you are an Apache CXF user, I can already hear you all saying (or even singing ?), Apache CXF: Nothing Else Matters ! Just make it loud enough to have your colleagues from the other team hear it :-)
Categories: Sergey Beryozkin

SurfCoastCentury 100km the video

Olivier Lamy - Fri, 10/09/2015 - 02:36
So I finally found a bit of time to make a movie (please be indulgent I'm not a professional :-) )

If you have read the run report, here the video:

Yes I enjoyed a LOT :-)

I hope after watching this, you will want to come here down under for a little run :-)
Categories: Olivier Lamy

Make your CXF JAX-RS servers OpenId Connect ready

Sergey Beryozkin - Thu, 10/08/2015 - 23:04
We've been doing a lot of work during the last year to ensure CXF developers can start experimenting fast and effectively with the latest RS security advancements such as OAuth2 and JOSE which are also the building blocks for OpenId Connect (OIDC).

With OAuth2 and JOSE modules becoming quite solid, it was time to turn the attention to OIDC, OIDC RP being a starting point - which is a mechanism to log on the users into the servers by federating to OIDC IDP providers such as Google and Facebook.  OIDC is a fairly complex protocol but with OAuth2 and JOSE covered it was not that tricky after all.

The initial result is these two demos:

1. BigQuery


This demo shows a client OAuth2 server that accesses a user's BigQuery data-sets. The demo checks a public data-set of Shakespeare works but once you have a Google Developer account you can easily create your own BigQuery data-set and use the demo to access it instead.

2. Basic OIDC

This demo shows that a server does not have to be specifically coded around OAuth2 flows to use OIDC - it only uses OIDC to log-in the users and then work with these users.

I'd like to encourage you to run these demos - ask at CXF users or #apache-cxf if you have any issues running them and start making your CXF servers OIDC-aware now !

I look forward to the feedback from the early adopters. And please watch this space - this is only a start :-)

Categories: Sergey Beryozkin

Apache CXF and Aries Blueprint Everywhere

Sergey Beryozkin - Wed, 10/07/2015 - 18:15
Many times, when developing JAX-RS demos, I had to solve the following issue: how to describe the demo endpoints to be run in OSGI and the same endpoints to be run in Tomcat.

Typically I'd create a Spring context file describing few JAX-RS endpoints and use it when running a demo in Tomcat. Next I'd create an equivalent Blueprint context file and run the demo in Karaf.

It works but having to duplicate the contexts in Spring and Blueprint languages is unfortunate. Granted, one can use Spring DM to run the endpoints described in Spring contexts in Karaf but OSGI developers know Spring DM is a finished line.

So we did some work first to make a CXFBlueprintServlet referencing a Blueprint context working in OSGI - the same way a CXFServlet can work with Spring contexts in OSGI with the help of Sprinjg DM.

Next, my colleague Alex suggested to have the same mechanism working in non-OSGI deployments - for the reason described above, i.e, to reuse the same context language (Blueprint) when deploying CXF endpoints to OSGI and servlet containers. As it happens Apache Aries team already did some work for supporting Blueprint in non-OSGI setups, so after doing some more work in CXF and Aries we can now have CXFBlueprintServlet loading Blueprint contexts in standalone Tomcat/Jetty too. Some work still needs to be done here, particularly ensuring such endpoints can run offline, but overall it looks promising.

The short overview is here.  Note the same web.xml and Blueprint context is used in OSGI and non-OSGI setups - the only thing which changes is a single Maven Aries dependency.

Note this mechanism works for CXF JAX-RS and JAX-WS endpoints.

If you are a Blueprint fan: Enjoy!  

Categories: Sergey Beryozkin

SurfCoastCentury 100km (my first ultra trail)

Olivier Lamy - Tue, 09/22/2015 - 05:45
I will try to tell you my journey to achieve this 100km trail called SurfcoatCentury because it happen on the surfcoast trails with some beach runs!
So I wanted to run this race maybe more than a year ago (even before my first marathon which I ran 12 october last year!).
But I have to train a lot first! Especially because I restarted doing sport seriously since around January 2013 (yup only for 18 months :-) ) after many years of very limited sport....
So during this year I managed to train a lot and do various long race bitumen and off road:
  • 17 May 2015: Great Ocean Road Marathon (44km )
  • 21 March 2015: RollerCoaster run (44km trail)
  • 11 January 2015: Two bays run (28km trail)
  • 12 Oct 2014: Melbourne Marathon
I remember someone saying: "your body must recover so you normally cannot run more than one or two marathons per year".
My answer was: "As my goal is to run 100km, those marathons are just training :-)"
Looking at the training log, I have 2000km running since 1st January 2015.
The hardest part was the 3 months before the big run. Despite a travel to France early July, I managed to run around 1200km from early June to the race (with a big August peak 470km). The France trip was not too bad as I ran a lot of off road compare to the city style suburb we live in Melbourne.
So here we are the big day!!!. Some stress coming!!! As I never ran more than 44km race (longest training was 48km) I don't know what will happen :-)
This start with the bag packing what to get what to wear etc... What to ask my great support crew to carry for various checkpoints...
The race start at 6.30am. We managed to find a house just 10 minutes walking from the start. For some reasons, I didn't want to ask my wife to drive me to a race start at 6.30am :-).
Obviously I didn't sleep a lot!
The program for today.

So here we are race start on a beach with an amazing sunrise!!! (for some reasons my wife prefer sunset over sunrise so she missed that one :P)



The first leg of the run is 21km of beach run: sand, cliff climbing and sometimes water until the knees (yup really wet shoes). Hopefully the sand is a bit humide so it's not soft sand.
The scenery is just amazing!!



After 21km we arrived at Torquay after passing trough beaches as Bells Beach, Point Addis (If you surf you know those mythics names). I managed to run those 21km in 2H30. Then I stopped 12 minutes. Yup that's too long as I didn't even change shoes but those long stops are the big mistake of this long run (but it was the first one so I didn't want to burn myself which I didn't for sure :-) ).
Now we are going back to Anglesea using the SurfCoast trails/walk (a mix of trail on the top of the cliff and a bit of bush) Again amazing scenery.


I'm happy as the family is here at Checkpoint3 so I got smiles and plenty of "Allez Papa!!" (Go Dad!!)






This leg2 is a bit more hilly: 28km with 520m elevation gain. I managed to run the first 11km with a good pace 6.22m/km then the last 17km at 7.20m/km.
I arrived at checkpoint 4 (mid race 50km) after 6h. Now time to change shoes/socks/t-shirt and got a lunch. I think here I made a BIG mistake as I stopped 35minutes!! Again I don't have the experience of such race so I did everything (eating/changing stuff) in a totally wrong order and do it bad. Next time: just have a printed TODO list with everything in a correct order. Other mistake I eat too much and too fast (sandwich and a banana) so my stomach was not really happy the next 15km :-(.



So now we start the leg 3 which is most difficult part of the race: 28km / 760 m elevation gain. Here an other completely different scenery with a real bush part!! You know the famous red/orange Australian ground and a bush forest!! And here I start to run long distance alone (the 50km runners are not here anymore) and runners are more streched after such distance.



But that's ok plenty of crazy birds!!. The first 20km are really good I managed a good 7.26m/km for this hilly part. But the next 7km are bad (really hard time in this last hard up hill): 9.13m/km during 7km (yup really slow!! especially I stopped too long at CP5 water point). I'm happy to finish this 3rd leg but a bit tired :-). I got help from Nicolas who is biking with me during the last part. So now an other smile time with the family at checkpoint 6. 77km done!! almost finished :-). An other mistake as I stopped too long again :-( (19minutes!!) but I was happy to have a chat with wife and kids.


So now time for the last leg, I still feel well (honestly you cannot give up after have done 77% of the race :-) ). The program is: 23km. Elevation gain / loss: 426m / 466m.


The first 9km are still a bit up/dow bush single track but then you are back to the ocean (you start thinking the finish line is not far anymore!!). Last checkpoint (CP7) (time to change for long sleeve and get head torch) wife/kids are here again for a last smile! See you "soon" at the finish line :-) This sunset really worth such a long run!! :-)





Now time to finish. But it's dark. I mean really dark as you are a middle nowhere without any lights from any cities.

And especially with the last beach run part around 4km (yup again beach run after 92km!!! Sacrebleu!!). So I do not see anything I just want to avoid running in the ocean :-).

Finally I can see lights wife/kids are here I can cross the line with the kids. That's it that's finished!! (yup you can't believe you only realise days after).





I believe I was crazy when I was thinking running this race more than a year ago. But now it's done and it was such an AMAZING experience.

It really worth all the hard training (wake up at 5am 5days/week during 2.5 months really need devotion/motivation the race is finally very easy compare to all the training).

I want to THANKS a lot wife and kids for all the support during this special and before when I was not here because training somewhere!!!

More details on my race here and the original race description (in a real good english :-) ).


My result. I'm happy to have finished (and with dignity). I think I could have made a better time especially with shorter break (but I'm French so I need long lunch break). It was my first experience on 100km so next one will be better :-)

And I already have some ideas for the next one. I'm pretty sure the family will be happy to visit the Blue mountains :-) ( see The north face 100 ).

I ran the race with a gopro so I have plenty of video materials to show you how Australia is such a beautiful country (but I need a bit of time to do it)
Categories: Olivier Lamy

Support for Jetty 9 in Apache CXF Fediz 1.3.0

Colm O hEigeartaigh - Fri, 09/18/2015 - 18:31
Yesterday I gave a tutorial on how to deploy the Apache CXF Fediz simpleWebapp example to Jetty 8 using Fediz 1.2.1. Apache CXF Fediz 1.3.0 will ship with a new plugin to support Jetty 9. In this post I will cover how to deploy the simpleWebapp example to Jetty 9 using this new plugin.

1) Deploying the 1.2.0 Fediz IdP in Apache Tomcat

As per the previous tutorial on deploying to Tomcat, we will deploy the IdP and STS in Apache Tomcat. Download Fediz and extract it to a new directory (${fediz.home}). To deploy the IdP to Tomcat:

  • Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
  • Download and copy the hsqldb jar (e.g. hsqldb-1.8.0.10.jar) to ${catalina.home}/lib
  • Copy idp-ssl-key.jks and idp-ssl-trust.jks from ${fediz.home}/examples/samplekeys to ${catalina.home}.
  • Edit ${catalina.home}/conf/server.xml and change the ports from 8080 -> 9080 + 8443 -> 9443 so as not to conflict with Jetty.
  • Edit the TLS Connector in ${catalina.home}/conf/server.xml' as well, e.g.: <Connector port="9443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="want" sslProtocol="TLS" keystoreFile="idp-ssl-key.jks" keystorePass="tompass" keyPass="tompass" truststoreFile="idp-ssl-trust.jks" truststorePass="ispass" />
Now start Tomcat, and check that the IdP is live by opening the STS WSDL in a web browser: 'https://localhost:9443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

2) Deploying the simpleWebapp in Jetty 9

Download Jetty 9 and extract it to a new directory (${jetty.home}). First let's set up TLS:
  • Copy ${fediz.home}/examples/samplekeys/rp-ssl-key.jks to ${jetty.home}/etc
  • Copy ${fediz.home}/examples/samplekeys/ststrust.jks to ${jetty.home} *and* to ${jetty.home}/etc
  • Edit ${jetty.home}/start.ini to include the ssl, https and fediz modules, and set up the TLS configuration as follows:
  •  The "fediz" module referred to above must be placed in ${jetty.home}/modules/fediz.mod with content:
Now we will deploy the simpleWebapp:
  • Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${jetty.home}/etc
  • Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
  • Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${jetty.home}/webapps
  • Create a new directory: ${jetty.home}/lib/fediz
  • Copy ${fediz.home}/plugins/jetty9/lib/* to ${jetty.home}/lib/fediz (note you may want to copy in a slf4j logging binding in here to see logging output, e.g. slf4j-jdk14-1.7.12.jar).
  • Create a new file in ${jetty.home}/webapps called "fedizhelloworld.xml" with content as follows, and then start Jetty as normal: 

3) Testing the service

To test the service navigate to:
  • https://localhost:8443/fedizhelloworld/  (this is not secured) 
  • https://localhost:8443/fedizhelloworld/secure/fedservlet
With the latter URL, the browser is redirected to the IDP (select realm "A") and is prompted for a username and password. Enter "alice/ecila" or "bob/bob" or "ted/det" to test the various roles that are associated with these username/password pairs.
Categories: Colm O hEigeartaigh

Deploying the Apache CXF Fediz simpleWebapp to Jetty

Colm O hEigeartaigh - Thu, 09/17/2015 - 18:41
On previous tutorials about Apache CXF Fediz, I have always described deploying the simpleWebapp example that ships with Fediz in Apache Tomcat. However, Fediz also supports deploying secured applications in Jetty (7 and 8 as of yet, support for Jetty 9 is forthcoming). As it can be somewhat confusing setting up the security requirements correctly, I will cover briefly how to deploy the simpleWebapp in Jetty 8 in this blog post (see the Fediz wiki for a dedicated page on deploying to Jetty).

1) Deploying the 1.2.0 Fediz IdP in Apache Tomcat

As per the previous tutorial on deploying to Tomcat, we will deploy the IdP and STS in Apache Tomcat. Download Fediz 1.2.1 and extract it to a new directory (${fediz.home}). To deploy the IdP to Tomcat:
  • Copy ${fediz.home}/idp/war/* to ${catalina.home}/webapps
  • Download and copy the hsqldb jar (e.g. hsqldb-1.8.0.10.jar) to ${catalina.home}/lib
  • Copy idp-ssl-key.jks and idp-ssl-trust.jks from ${fediz.home}/examples/samplekeys to ${catalina.home}.
  • Edit ${catalina.home}/conf/server.xml and change the ports from 8080 -> 9080 + 8443 -> 9443 so as not to conflict with Jetty.
  • Edit the TLS Connector in ${catalina.home}/conf/server.xml' as well, e.g.: <Connector port="9443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="want" sslProtocol="TLS" keystoreFile="idp-ssl-key.jks" keystorePass="tompass" keyPass="tompass" truststoreFile="idp-ssl-trust.jks" truststorePass="ispass" />
Now start Tomcat, and check that the IdP is live by opening the STS WSDL in a web browser: 'https://localhost:9443/fediz-idp-sts/REALMA/STSServiceTransport?wsdl'

2) Deploying the simpleWebapp in Jetty 8

Download Jetty 8 and extract it to a new directory (${jetty.home}). First let's set up TLS:
  • Copy ${fediz.home}/examples/samplekeys/rp-ssl-key.jks to ${jetty.home}/etc
  • Copy ${fediz.home}/examples/samplekeys/ststrust.jks to ${jetty.home} *and* to ${jetty.home}/etc
  • Edit ${jetty.home}/start.ini and make sure that 'etc/jetty-ssl.xml' is included.
  • Edit ${jetty.home}/etc/jetty-ssl.xml and configure the TLS keys, e.g.:


Now we will deploy the simpleWebapp:
  • Copy ${fediz.home}/examples/simpleWebapp/src/main/config/fediz_config.xml to ${jetty.home}/etc
  • Do a "mvn clean install" in ${fediz.home}/examples/simpleWebapp
  • Copy ${fediz.home}/examples/simpleWebapp/target/fedizhelloworld.war to ${jetty.home}/webapps
  • Create a new directory: ${jetty.home}/lib/fediz
  • Copy ${fediz.home}/plugins/jetty/lib/* to ${jetty.home}/lib/fediz (note you may want to copy in a slf4j logging binding in here to see logging output, e.g. slf4j-jdk14-1.7.12.jar).
  • Edit ${jetty.home}/start.ini and add "fediz" to "OPTIONS".
  • Create a new file in ${jetty.home}/contexts called "fedizhelloworld.xml" with content as follows, and then start Jetty as normal:

3) Testing the service

To test the service navigate to:
  • https://localhost:8443/fedizhelloworld/  (this is not secured) 
  • https://localhost:8443/fedizhelloworld/secure/fedservlet
With the latter URL, the browser is redirected to the IDP (select realm "A") and is prompted for a username and password. Enter "alice/ecila" or "bob/bob" or "ted/det" to test the various roles that are associated with these username/password pairs.
    Categories: Colm O hEigeartaigh

    Authorization for web services using XACML 3.0

    Colm O hEigeartaigh - Tue, 09/08/2015 - 16:29
    In a blog post last year, I covered some authentication and authorization test-cases for Apache CXF-based web services that I uploaded to github. In particular, the cxf-sts-xacml demo showed how a CXF service can use XACML to authorize a web service request, by sending a XACML request to a Policy Decision Point (PDP) and then by enforcing the authorization decision. This demo only covered XACML 2.0 (provided by OpenSAML). In this post we will give an example of how to use XACML 3.0 via Apache OpenAz to make and enforce authorization requests for Apache CXF based services.

    1) Introducing Apache OpenAz

    The XACML functionality in Apache CXF is based on OpenSAML, which provides support for XACML 2.0. However, XACML 3.0 is an OASIS standard as of January, 2013. A new project in the Apache Incubator called Apache OpenAz addresses this gap. The source code is broken down into the following modules:
    • openaz-xacml - API + common functionality.
    • openaz-xacml-rest - Some common functionality used by the RESTful API interfaces
    • openaz-xacml-pdp - A PDP implementation
    • openaz-xacml-pdp-rest - An implementation of the XACML 3.0 RESTful Interface for the PDP
    • openaz-xacml-pap-rest - An implementation of the XACML 3.0 RESTful Interface for the PAP
    • openaz-xacml-test - Some testsuites
    • openax-pep -  The PEP (Policy Enforcement Point) implementation.
    2) Integrating Apache OpenAz with Apache CXF

    The testcases are available here:
    • cxf-sts-xacml: This project contains a number of tests that show how to use XACML with CXF to authorize a client request. It contains both XACML 2.0 tests and XACML 3.0 tests.
    In both cases, the client obtains a SAML Token from the STS with the roles of the client embedded in the token. The service provider extracts the roles, and creates a XACML request. For the XACML 2.0 case, OpenSAML is used to create a XML XACML 2.0 request. This is then sent to a mocked PDP JAX-RS service. However, let's focus on the XACML 3.0 case. In this test, the OpenAz API (via the openaz-xacml module as covered above) is used to create a JSON XACML 3.0 request. This is evaluated by a OpenAz-based PDP which is co-located with the service. After evaluating the request, the PDP response is then enforced at the service side.

    The service endpoint is configured in Spring as follows, registering a XACML3AuthorizingInterceptor (which in turn contains a reference to the co-located PDP):

    The XACML3AuthorizingInterceptor is configured with a implementation to create a XACML 3.0 request using the SAML 2.0 profile of XACML 3.0, which is subsequently converted into JSON + sent to the PDP. The PDP is configured with "root" and "reference" policies, that state that a user of role "boss" has permission to "execute" the Web Service Operation "{http://www.example.org/contract/DoubleIt}DoubleItService#DoubleIt". For example:
    A sample authorization request looks like:
    If you are interested in XACML 3.0 please get involved with the Apache OpenAz project! Once the project gets more mature, the PEP code in my project will probably make it over to Apache CXF so that users have the option of supporting XACML 2.0 or 3.0 (and XML or JSON) with their web services.
    Categories: Colm O hEigeartaigh

    Apache CXF Fediz 1.2.1 and 1.1.3 released

    Colm O hEigeartaigh - Thu, 08/27/2015 - 18:50
    Apache CXF Fediz 1.2.1 and 1.1.3 have been released. Both releases contain updates to the underlying CXF dependency, as well as a number of minor bug-fixes and improvements. However the most important enhancement is a fix for a recent security advisory:
    • CVE-2015-5175: Apache CXF Fediz application plugins are vulnerable to Denial of Service (DoS) attacks
    Apache CXF Fediz is a subproject of Apache CXF which implements the WS-Federation Passive Requestor Profile for SSO specification. It provides a number of container based plugins to enable SSO for Relying Party applications. These plugins are potentially vulnerable to DoS attacks due to the fact that support for Document Type Declarations (DTDs) is not disabled when parsing the response from the Identity Provider (IdP).
    Categories: Colm O hEigeartaigh

    Apache CXF Fediz 1.2.0 tutorial - part VII

    Colm O hEigeartaigh - Tue, 08/25/2015 - 17:36
    This is the seventh and final blog post on a series of new features introduced in Apache CXF Fediz 1.2.0. The previous post looked at the new REST API of the IdP. Up to now, we have only covered the basic scenario where the application and the IdP are in the same realm. However, a more sophisticated example is when the application is in a different realm. In this case, the IdP must redirect the user to the home IdP of the application for authentication. The IdP has supported this functionality up to now using WS-Federation only. However, the 1.2.0 IdP supports the ability to redirect to a SAML SSO IdP, thus acting as an identity broker between the two protocols. We will cover this functionality in this tutorial.

    1) Setup simpleWebapp + SAML SSO IdP

    As with previous tutorials, please follow the first tutorial to deploy the Fediz IdP + STS to Apache Tomcat, as well as the "simpleWebapp. However, this time the "simpleWebapp" is going to be deployed in a different realm. Edit 'conf/fediz_config.xml' and add the following under the "protocol" section:
    • <homeRealm type="String">urn:org:apache:cxf:fediz:idp:realm-B</homeRealm>
    This tells the IdP that the application is to be authenticated in "realm-B".

    The next thing we are going to do is to set up a SAML SSO IdP which will authenticate users who want to access "simpleWebapp". In this tutorial we will just use a mocked SAML SSO IdP in the Fediz system tests for convenience. Build the war as in the following steps + deploy to Tomcat:
    2) Configure the Fediz IdP

    Next we need to take a look at configuring the Fediz IdP so that it knows where to find the SAML SSO IdP associated with "realm B" and how to communicate with it. Edit 'webapps/fediz-idp/WEB-INF/classes/entities-realma.xml':

    In the 'idp-realmA' bean:
    • Change the port in "idpUrl" to "8443". 
    In the 'trusted-idp-realmB' bean:
    • Change the "url" value to "https://localhost:8443/samlssoidp/samlsso".
    • Change the "protocol" value to "urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser".
    • Add the following: <property name="parameters"><util:map><entry key="support.deflate.encoding" value="true" /></util:map></property>
    The "parameters" map above is a way to provide SAML SSO specific configuration options to the Fediz IdP. The following options can be configured:
    • sign.request - Whether to sign the request or not. The default is "true".
    • require.keyinfo - Whether to require a KeyInfo or not when processing a (signed) Response. The default is "true".
    • require.signed.assertions - Whether the assertions contained in the Response must be signed or not. The default is "true".
    • require.known.issuer - Whether we have to "know" the issuer of the SAML Response or not. The default is "true".
    • support.base64.encoding - Whether we BASE-64 decode the response or not. The default is "true".
    • support.deflate.encoding - Whether we support Deflate encoding or not. The default is "false".
    Redeploy the Fediz IdP + navigate to the following URL in a browser:
    • https://localhost:8443/fedizhelloworld/secure/fedservlet
    You will see that the Fediz IdP will redirect the browser to the mocked SAML SSO IdP for authentication (authenticate with "ALICE/ECILA") and then back to the Fediz IdP and eventually back to the client application.


    Categories: Colm O hEigeartaigh

    Apache CXF Fediz 1.2.0 tutorial - part VI

    Colm O hEigeartaigh - Wed, 08/19/2015 - 17:55
    This is the sixth in a series of posts on the new features of Apache CXF Fediz 1.2.0. The previous post looked at Single Sign Out support in Fediz. In this article we will briefly cover the new REST API of the Fediz IdP. Prior to the 1.2.0 release all of the IdP configuration was done in a static way using Spring. If the IdP administrator wished to change the claims for a particular application, then the change would necessitate restarting the IdP. In contrast, the Fediz 1.2.0 IdP persists the configuration to a database using JPA. In addition, it allows access to this configuration via a REST API powered by Apache CXF.

    To get started, please follow step 1 of the first tutorial to deploy the Fediz IdP to Apache Tomcat. The REST API is described by a WADL document available at the following URL:
    • https://localhost:8443/fediz-idp/services/rs?_wadl
    The WADL document describes the following resource URIs:
    • services/rs/idps - An IdP for a given realm. 
    • services/rs/claims - The claims that are available in the IdP.
    • services/rs/applications - The applications that are defined in the IdP.
    • services/rs/trusted-idps - The trusted IdPs that are defined in the IdP.
    • services/rs/roles - The roles associated with the REST API.
    By using the standard HTTP verbs in the usual way you can retrieve, store, modify and remove items from the IdP configuration. For example, to see (GET) the configuration associated with the IdP for "realm A" navigate to the following URL in a browser:
    • https://localhost:8443/fediz-idp/services/rs/idps/urn:org:apache:cxf:fediz:idp:realm-A
    The user credentials are defined in "webapps/fediz-idp/WEB-INF/classes/users.properties". You can use "admin/password" by default to access the API. Here you can see the protocols supported, the token types offered, the different ways of authenticating to the IdP, the claim types offered, the applications supported, etc. Note that by default the information returned in a GET request is in XML format. You can return it in JSON format just by appending ".json" to the URL:
    For much more information on how to use the new REST API, please see Oliver Wulff's blog on this topic.
    Categories: Colm O hEigeartaigh

    Apache CXF Fediz 1.2.0 tutorial - part V

    Colm O hEigeartaigh - Fri, 08/07/2015 - 18:43
    This is the fifth in a series of posts on the new features available in Apache CXF Fediz 1.2.0. The previous article described a new container-independent Relying Party (RP) plugin available in Fediz 1.2.0 based on Apache CXF. In this post we will take a look at two new features, support for Single Sign Out and the ability to publish metadata for both RP plugins and the IdP.

    1) Single Sign Out support in Fediz

    An important new feature in Fediz 1.2.0 is the ability to perform Single Sign Out both at the RP and IdP. The user can log out at either the RP or IdP by adding "?wa=wsignout1.0" to the relevant URL. Alternatively, two new configuration options are added for the RP:
    • logoutURL - The logout URL to trigger federated logout
    • logoutRedirectTo - URL landing-page after successful logout.
    To see how this works in practice, follow the first tutorial to set up the hello world demo in Tomcat, and log on via:
    • https://localhost:8443/fedizhelloworld/secure/fedservlet
    After successful authentication, you will see a basic webpage detailing the User principal, roles, and the underlying SAML Assertion. Now what if you want to log out from the application? From Fediz 1.2.0 it's simple. Navigate to the following URL:
    • https://localhost:8443/fedizhelloworld/secure/fedservlet?wa=wsignout1.0
    The browser will be redirected to the logout page for the IdP:

    Click "Logout" and you see a page confirming that Logout was successful (in both the RP + IdP). To confirm this, navigate again to the application URL, and you will see that you are redirected back to the IdP for authentication. The user can also logout directly at the IdP by navigating to:
    • https://localhost:8443/fediz-idp/federation?wa=wsignout1.0
    2) Metadata Support in Fediz

    It has been possible since Fediz 1.0.0 to publish the Metadata document associated with a Relying Party using the Tomcat plugin. This Metadata document is built dynamically using the Fediz configuration values and is published at the standard URL. Here is a screenshot of a request using the "fedizhelloworld" demo:

    This document describes the endpoint address of the service, the realm of the service, and the claims (both required and optional). The metadata document can also be signed by specifying a "signingKey" in the Fediz configuration.

    So what's new in Fediz 1.2.0? The first thing is that it was only possible previously to publish the metadata document when using the Tomcat plugin. In Fediz 1.2.0, this has been extended to cover the other plugins, i.e. Jetty, Spring, etc. In addition, the forthcoming Fediz 1.2.1 release adds support for Metadata to the IdP. The Metadata is available at the same standard URL as for the RP, e.g.:

    This signed document describes the URL of the STS, as well as that of the IdP itself, and the claims that are offered by the IdP.
    Categories: Colm O hEigeartaigh

    Karaf Tutorial Part 4 - CXF Services in OSGi

    Christian Schneider - Wed, 08/05/2015 - 10:44

    Blog post edited by Christian Schneider

    Shows how to publish and use a simple REST and SOAP service in karaf using cxf and blueprint.

    To run the example you need to install the http feature of karaf. The default http port is 8080 and can be configured using the
    config admin pid "org.ops4j.pax.web". You also need to install the cxf feature. The base url of the cxf servlet is by default "/cxf".
    It can be configured in the config pid "org.apache.cxf.osgi".

    Differences in Talend ESB

    Icon

    If you use Talend ESB instead of plain karaf then the default http port is 8044 and the default cxf servlet name is "/services".

    PersonService Example

    The "business case" is to manage a list of persons. As service should provide the typical CRUD operations. Front ends should be a REST service, a SOAP service and a web UI.

    The example consists of four projects

    • model: Person class and PersonService interface
    • server: Service implementation and logic to publish the service using REST and SOAP
    • proxy: Accesses the SOAP service and publishes it as an OSGi service
    • webui: Provides a simple servlet based web ui to list and add persons. Uses the OSGi service

    You can find the full source on github: https://github.com/cschneider/Karaf-Tutorial/tree/master/cxf/personservice

    Installation and test run

    First we build, install and run the example to give an overview of what it does. The following main chapter then explains in detail how it works.

    Installing Karaf and preparing for CXF

    We start with a fresh Karaf 2.3.1.

    Installing CXF

    In Karaf Console run

    features:chooseurl cxf 2.7.4 features:install http cxf

    Changes in commands for karaf 3

    Icon
    • features:chooseurl -> feature:repo-add
    • features:install -> feature:install
    Build and Test

    Checkout the project from github and build using maven

    > mvn clean install

    Install service and ui in karaf install -s mvn:net.lr.tutorial.karaf.cxf.personservice/personservice-model/1.0-SNAPSHOT install -s mvn:net.lr.tutorial.karaf.cxf.personservice/personservice-server/1.0-SNAPSHOT install -s mvn:net.lr.tutorial.karaf.cxf.personservice/personservice-proxy/1.0-SNAPSHOT install -s mvn:net.lr.tutorial.karaf.cxf.personservice/personservice-webui/1.0-SNAPSHOT Test the service

    The person service should show up in the list of currently installed services that can be found herehttp://localhost:8181/cxf/

    List the known personshttp://localhost:8181/cxf/person
    This should show one person "chris"

    Now using a firefox extension like Poster or Httprequester you can add a person.

    Send the following xml snippet:

    <?xml version="1.0" encoding="UTF-8"?> <person> <id>1001</id> <name>Christian Schneider</name> <url>http://www.liquid-reality.de</url> </person>

    with Content-Type:text/xml using PUT:http://localhost:8181/cxf/person/1001
    or to this url using POST:http://localhost:8181/cxf/person

    Now the list of persons should show two persons.

    Test the proxy and web UI

    http://localhost:8181/personui

    You should see the list of persons managed by the personservice and be able to add new persons.

    How it worksDefining the model

    The model project is a simple java maven project that defines a JAX-WS service and a JAXB data class. It has no dependencies to cxf. The service interface is just a plain java interface with the @WebService annotation.

    @WebService public interface PersonService { public abstract Person[] getAll(); public abstract Person getPerson(String id); public abstract void updatePerson(String id, Person person); public abstract void addPerson(Person person); }

    The Person class is just a simple pojo with getters and setters for id, name and url and the necessary JAXB annotations. Additionally you need an ObjectFactory to tell JAXB what xml element to use for the Person class.
    There is also no special code for OSGi in this project. So the model works perfectly inside and outside of an OSGi container.

    Icon

    The service is defined java first. SOAP and rest are used quite transparently. This is very suitable to communicate between a client and server of the same application. If the service
    is to be used by other applications the wsdl first approach is more suitable. In this case the model project should be configured to generate the data classes and service interface from
    a wsdl (see cxf wsdl_first example pom file). For rest services the java first approach is quite common in general as the client typically does not use proxy classes anyway.

    Service implementation (server)

    PersonServiceImpl is a java class the implements the service interface and contains some additional JAX-RS annotations. The way the class is defined allows it to implement a REST service and a SOAP service at the same time.

    The server project also contains a small starter class that allows the service to be published directly from eclipse. This class is not necessary for deployment in karaf.

    The production deployment of the service is done in src/main/resources/OSGI-INF/blueprint/blueprint.xml.

    As the file is in the special location OSGI-INF/blueprint it is automatically processed by the blueprint implementation aries in karaf. The REST service is published using the jaxrs:server element and the SOAP service is published using the jaxws:endpoint element. The blueprint namespaces are different from spring but apart from this the xml is very similar to a spring xml.

    Service proxy

    The service proxy project only contains a blueprint xml that uses the CXF JAXWS client to consume the SOAP service and exports it as an OSGi Service. Encapsulating the service client as an OSGi service (proxy project) is not strictly necessary but it has the advantage that the webui is then completely independent of cxf. So it is very easy to change the way the service is accessed. So this is considered a best practice in OSGi.

    See blueprint.xml

    Web UI (webui)

    This project consumes the PersonService OSGi service and exports the PersonServlet as an OSGi service. The pax web whiteboard extender will then publish the servlet on the location /personui.
    The PersonServlet gets the PersonService injected and uses to get all persons and also to add persons.

    The wiring is done using a blueprint context.

    Some further remarks

    The example uses blueprint instead of spring dm as it works much better in an OSGi environment. The bundles are created using the maven bundle plugin. A fact that shows how well blueprint works
    is that the maven bundle plugin is just used with default settings. In spring dm the imports have to be configured as spring needs access to many implementation classes of cxf. For spring dm examples
    take a look at the Talend Service Factory examples (https://github.com/Talend/tsf/tree/master/examples).

    The example shows that writing OSGi applications is quite simple with aries and blueprint. It needs only 153 lines of java code (without comments) for a complete little application.
    The blueprint xml is also quite small and readable.

    Back to Karaf Tutorials

    View Online
    Categories: Christian Schneider

    Pages

    Subscribe to Talend Community Coders aggregator