16 October 2014

Recently I had to develop some extensions (ClaimHandler, Validator) to the CXF STS. My problem at first was, how to write an integration test that proves the correct implementation of my extensions.

At first I placed my Mockup classes and web config in the src/main folder from my maven project and added the jetty plugin to my pom.xml file. This way I was able to start my REST MockupService simply by typing mvn jetty:run on the console. After starting the service I was able to execute my test classes directly from Eclipse. But this approach did not satisfy me at all, because now I had lots of files in my main project folder, which would not be needed once I build and deploy my STS extensions to another STS installation. Somehow I needed to move all files (Mockup Service, Spring beans.xml, web.xml, etc.) to the test project folder.

In this post I'll explain how to setup you maven pom file so that you can use Jetty in your integration test phase if your packaging goal is not a war file but a simple jar file instead and all your web configuration and classes are located in your test folder.

14 October 2014

In a previous post I've explained how to setup a demo application using SAML token for authentication and XACML for authorization in context of REST services.
In this blog I'm going to explain how to setup the Talend PDP ouside of the OSGi container in which it is usually located, so that you are able to use the PDP co-located to your demo application in any JavaEE container. This is especially helpful if your application cannot easily being deployed into the Talend runtime, but requires lots of authorization requests. In these cases it will be best to have the PDP co-located with your app, completely avoiding expensive network calls.

13 October 2014

Identity and claim mapping become important, when the target realm (A) of a web application is not equal to the home realm (B) of the user. In this case a SAML token from the user (issuer B) cannot directly be validated at the web application (trusting issuer A only). The relaying party IDP of the web application (in realm A) is able to exchange the SAML token from the (trusted) home realm (B) into a SAML token applicable for the target realm (A). This exchange can be based either on identity mapping or on claim mapping. In this post I'm going to explain what's the difference between these two mapping styles and when to use which alternative.

01 October 2014

Before CXF version 2.7.13 it was quite difficult to use claim mappings in the STS, because CXF did not provide any generic claim mapping solution but instead required custom Java code for each claim mapping. Beginning of version 2.7.13 (not yet released) CXF comes with a JexlClaimsMapper which allows to define claim mappings at configuration time with Java Expression Language (JEXL).
Also a new feature in CXF which goes hand in hand with the JexlCaimsMapper is a special ClaimUtils class providing methods for common claim handling tasks.

About Me

I am a technical consultant working for Talend in the application integration (ESB) department. I enjoy focusing on security related topics at the most. I'm a committer for Apache CXF and Apache Syncope. The views expressed on this site are mine alone and do not necessarily reflect the views of my employer.

Disclaimer

I hope this content helps you to better understand some topics. All content of this blog is created to my best knowledge. I don't claim to know everything and to be error free. Therefore you must use any information on this page at your own risk.If you find errors please leave me a note in the comments and I'll do my best to take care of it.