Latest Activity

No Data No Fun !

Sergey Beryozkin - Tue, 12/23/2014 - 23:17
Continuing with the theme of T-shirts, I'd like to let you know "No Data No Fun" is a cool line printed on my T-shirt I got at a Talend R&D summit organized at a second-to-none level back in early October. I guess having a collection of good T-Shirts is one of the real perks of the developers involved into the open source development :-)

"No Data No Fun" is also one of the themes behind Talend's continued investment into the tooling which facilitates the interaction with Big Data ecosystems. Getting such a tooling done right is hard. I'm impressed seeing companies like Lenovo liking it.

From my point of view, I'm interested to see how an apparent gap between the world of a typical HTTP service application and that of a Big Data one can be bridged. Ultimately web applications are about exploring the data and feeding them back to the users. We've done the first baby step, provided a FIQL to HBase query client that can be used to query massive amounts of data from HBase databases. JAX-RS StreamingOutput would very neatly fit in there.

However, it is also interesting to see how CXF services can be run natively in Hadoop, to save on a data delivery from HBase or other Hadoop-bound database to a query client running in scope of the CXF server, much cheaper to get it straight from Hadoop and send it back immediately. This is something I'm hoping to find some time for investigating next year. Propagating Kerberos or OAuth2 tokens into Hadoop/etc is also of interest.

I hope CXF will help you get a lot of data from Hadoop and have a lot of fun along the way :-) 

Categories: Sergey Beryozkin

Get into OAuth2 with Client Credentials Grant

Sergey Beryozkin - Tue, 12/23/2014 - 22:42
One of the possible barriers toward OAuth2 going completely mainstream is the likely association of OAuth2 with what big social media providers do and the assumption OAuth2 is only suitable for their business, for the way their users interact with these providers.

In fact, OAuth2 is more embracing. Client Credentials grant, one of several standard OAuth2 grants,  provides the easy path for the traditional clients toward starting working with security tokens.

The client, instead of doing the authentication with a name and a password (or some other client credentials) against the target service endpoint on every request (and thus having to keep these secrets for a long time) does it only once, against OAuth2 AccessTokenService which accepts various grants and returns manageable tokens with a restricted lifetime. Such tokens can be obtained out-of-band, with the client applications initialized with the tokens. The client will use the token only when authenticating against the endpoint. It is still a secret in its own way but it is a transient one that can be revoked by the administrator or by the client itself.

The client credentials grant provides for an easy and fast way into the OAuth2 ecosystem. Consider experimenting with it sooner rather than waiting for another 5 years :-), discover the OAuth2 world along the way, find how OAuth2 can positively affect your applications, and never look back again !  
Categories: Sergey Beryozkin

New SSL/TLS vulnerabilities in Apache CXF

Colm O hEigeartaigh - Mon, 12/22/2014 - 13:01
Apache CXF 3.0.3 and 2.7.14 have been released. Both of these releases contain fixes for two new SSL/TLS security advisories:
  • Note on CVE-2014-3566: This is not an advisory per se, but rather a note on an advisory. CVE-2014-3566 (aka "POODLE") is a well publicised attack which forces a TLS connection to downgrade to use SSL 3.0, which in turn is vulnerable to a padding oracle attack. Apache CXF 3.0.3 and 2.7.14 disable SSL 3.0 support by default for both clients, as well as servers configured using CXF's special support for Jetty. In addition, it is now possible to explicitly exclude protocols, see here for more information.
  • CVE-2014-3577: Apache CXF is vulnerable to a possible SSL hostname verification bypass, due to a flaw in comparing the server hostname to the domain name in the Subject's DN field. A Man In The Middle attack can exploit this vulnerability by using a specially crafted Subject DN to spoof a valid certificate.
If you are using TLS with Apache CXF then please upgrade to the latest releases.
Categories: Colm O hEigeartaigh

Apache Karaf Christmas gifts:, profiles, and decanter

Jean-Baptiste Onofré - Mon, 12/15/2014 - 14:12
We are heading to Christmas time, and the Karaf team wanted to prepare some gifts for you Of course, we are working hard in the preparation of the new Karaf releases. A bunch of bug fixes and improvements will be available in the coming releases: Karaf 2.4.1, Karaf 3.0.3, and Karaf 4.0.0.M2. Some sub-project releases […]
Categories: Jean-Baptiste Onofré

Understanding WS-Federation - Passive Requestor Profile

Jan Bernhardt - Thu, 12/11/2014 - 10:45
WS-Federation  is an identity federation specification which makes it possible to setup a SSO federation including multiple security realms. A realm (sometimes also called domain) represents a single unit under security administration or a part in a trust relationship.
EntitiesWithin the WS-Federation standard the following entities are defined:
  • Relying Party (RP)
    The relying party is a resource (web application or service) which consumes security tokens issued by the Security Token Service.
  • Requestor
    A requestor is a user who wants to access a resource (relying party).
  • Identity Provider (IDP)
    An Identity Provider can act as an authentication service to a requestor (in this case it is also called “Requestor IDP” or “Home-Realm IDP”) as well as an authentication service to a service provider (also called “Relying Party IDP”). If a user tries to access a relying party within his own security domain, the “Requestor IDP” and the “RP-IDP” can be the same IDP instance. An IDP can also be seen as an Web-Frontend (Extension) of an STS.
  • Security Token Service (STS)
    A Security Token Service is a web service that validates user credentials and issues security tokens which can include user attributes (also called claims). The security token can be used at the Relying Party to authenticate the requestor’s identity.
Passive Requestor ProfileThe “Passive Requestor Protocol”  of the WS-Federation standard deals with web-browser based access of a resource like a web portal or a web application.

The following figure shows a standard scenario of a web application (Relying Party) which delegates the user authentication to an Identity Provider (IDP) according to the WS Federation standard. This way the web application does not need to implement multiple authentication styles for a user, as well as it allows interacting with users not known within the local security domain. Another benefit of delegating the authentication process is that the IDP can retain a session with the user, so that when a user accesses another web application and is redirected to the IDP again, the IDP does not need to request user credentials again und thus providing a SSO experience for the user.

The above figure shows a sequence diagram of a user (requestor) accessing a web application with his browser. Since the user was not authentication due to a recent session, the application redirects the user to the IDP for a user login (1). The IDP collects the credentials from the user and uses a Security Token Service (STS) to validate the credentials and also to get a SAML token from the STS (2). The STS itself is connected to a LDAP data store to validate the user credentials and also to retrieve additional information (claims) about the user, e.g. roles. On successful authentication (3) the IDP returns the SAML token issued by the STS (4) to the user and advices (auto-submitting form) the user to send this SAML token to the originally requested web application (5). The IDP takes care of providing a web user interface and handling URL redirects, whereas the STS is responsible for generating SAML Token and validating of user credentials. The web application validates the SAML token (6) and on success returns the desired web page (7).

The above sample was designed to show a simple use case scenario where the Requestor IDP is equal to the Relying Part IDP. In a more sophisticated scenario the Requestor IDP will not be equal to the Relying Party IDP. In addition to that there is also a Reverse Proxy added to the web application ensuring that the home realm discovery (also see section 2.3.3) is going to work correctly. The resulting access sequence can be seen in the following figure.

The user enters the public WebApp URL in his browser which leads him to the Reverse Proxy (0). The WebApp has no recent session with the user and therefore does not know the identity of the user. Thus the WebApp redirects the user to its Relying Party IDP (1). The Reverse Proxy detects the redirect to the RP-IDP and adds a home realm parameter for the user (1). This IDP uses this home realm parameter to perform the home realm discovery (3) and thus knowing at which IDP can be redirected to for being authenticated (4). The WS-Federation standard does not define how the home realm discovery should be performed. Multiple options are usually available:
  • User Selection
    A list of known and trusted IDPs is shown to the user. The user selects the IDP at which he wants to be authenticated and is then redirected to that IDP.
  • IP Discovery
    The user will be redirected automatically to another IDP based on his IP address.
  • whr Parameter
    The URL to invoke the RP-IDP contains an additional ‘whr’ parameter to define the IDP name on which the user wants to be redirected to for authentication. The ‘whr’ parameter must be known at the RP-IDP and must either be mapped to an URL or can also already be the URL of another IDP). The ‘whr’ parameter is usually set by a Reverse Proxy or was added (by the user or a provided link) in the URL when initially calling the web application.
  • Custom Discovery
    Any custom logic can be added to the IDP to perform the home realm discovery. The standard is not limited to any predefined behaviour.
After being redirected to the users home IDP (5) the IDP also has no recent session with the user and thus shows a login form to the user to enter his credentials (6). The user sends his username/password to the IDP, which itself creates an issue request to the STS with the received unsername/password embedded (7). The STS validates the user credentials by using the LDAP. Upon successful authentication the STS retrieves the requested user claims (e.g. roles) from the LDAP (8) and creates a SAML token (9) targeted for the RP-IDP. The Requestor IDP embeds this SAML token inside an auto-submitting (Java Script) web form (10) which is then posted to the RP-IDP (11a). The RP-IDP is now able to use this SAML token to authenticate on behalf of the user against the RP STS (11b) to request a SAML token for the previously requested web application. The RP-STS needs to perform an identity or claim mapping (12) to issue a second SAML token this time applicable for the requested web application (13). The RP-IDP puts this application specific SAML token again in a self-executing HTTP form (14) which is then automatically submitted to the web application via the reverse proxy (15). The Relying Party (the web application) validates the received SAML token by verifying that the issuer certificate of the SAML token is trusted. This should be the case, since the SAML token was issued by its own Relying Party IDP. Additional claims like the user roles can be added to the security context of the web application and thus allowing authorization above authentication.
Categories: Jan Bernhardt

XML Security using Apache Camel

Colm O hEigeartaigh - Tue, 12/02/2014 - 15:48
I have previously covered how to use Apache Santuario to sign and encrypt XML, using both the DOM and StAX based APIs available in the 2.0.x releases. An alternative to using Apache Santuario directly to sign/encrypt XML, is to use the XML Security component or data format of Apache Camel. There are two obvious reasons to use Camel that immediately spring to mind. Firstly it allows you to configure XML Signature/Encryption without writing any code (e.g. by configuring the components in Spring). Secondly it allows you to take advantage of the power and flexibility of Apache Camel to integrate with a wide variety of components.

I have created a github project with two (almost identical) tests to show how to use XML Signature and Encryption in Apache Camel:
Both tests start routes which read in XML documents stored in src/test/resources/data using the Camel File component. The part of the documents which contain credit card information is then signed/encrypted, and the resulting file placed in the target/(encrypted/signed)-data folder. A second route reads files in from this folder, decrypts/verifies the file and then places it in the target/(decrypted/verified)-data folder.

The encryption configuration file is available here, and the signature configuration file is here. One difference you may notice is that encryption is configured using a "marshal/unmarshal" tag and then "secureXML", whereas for signature you can use a standard Camel "To" statement, e.g. "
<to uri="xmlsecurity:sign://enveloped?keyAccessor...". This is due to the fact that XML Encryption is implemented in Camel as a data format, whereas XML Signature is implemented as a component.

Both tests also use the Camel Jasypt component to avoid hard-coding plaintext passwords in the spring configuration files. The keystore and private key passwords and stored encrypted in a special passwords file. The master secret used to decrypt the passwords is retrieved via a system property (set in the pom.xml as part of the tests).

The testcase relies on a SNAPSHOT version of Apache Camel for now (2.15-SNAPSHOT) due to a number of fixes I added. Firstly, the DefaultKeySelector used to retrieve keys for signature did not previously support taking a Camel
keyStoreParameters Object. Secondly, the DefaultKeySelector did not support working with the Camel Jasypt component to encrypt the keystore password.  Thirdly, it wasn't possible to load a Public Key from a PrivateKeyEntry in a Keystore for XML Signature. Fourthly, the XML Encryption data format did not support embedding the KeyValue of the Public Key used to encrypt the session key in the EncryptedKey structure.
Categories: Colm O hEigeartaigh

Observations about ApacheCon EU 2014

Sergey Beryozkin - Mon, 11/24/2014 - 00:03
You may be thinking now, after reading my previous post, that all I was doing at ApacheCon EU 2014 was looking at T-shirts people were wearing :-). This post is an attempt to convince you it was not the case.

First of all, ApacheCon EU 2014, as it is usually the case with Apache conferences, was a great opportunity to meet the fellow open source developers.
Chatting to the guys I work with at Apache CXF and other projects, sharing a joke or two along the way :-), was really great. 

Some people there are great advocates of doing the software for the good of the world. You do see people there who spend their own free time to make Apache and various projects it hosts succeed and help others.

It was nice to see Talend, my employer, being mentioned as one of Apache sponsors. Even though Apache has great sponsors which contribute much more, it was good to see Talend being recognized. Every contribution counts. The companies involved in the open source have a positive vibe about them, the more they are involved the more recognized and respected in the community at large they become. The world is a small place. Customers would be positive about working with such companies, going the business with such companies, as this post posted awhile back suggested.

Those of us who did the presentations about CXF were lucky to do it on the very first day in a beautiful Corinthia Hotel Ballroom. I kept thinking, there were times people were dancing there accompanied by the music by Franz Liszt and here we are talking the cryptic things about CXF.  The times change. But the beauty of the room is there today.

The other thing I noticed was the visibility of Hortonworks. They had a strong team presenting a number of interesting talks. To be fair to them, their T-shirts are also not bad at all :-), may be they should have some sort of the competition with Tomitribe.

Overall, it was a well organized, great event ! I'm feeling positive and energized after attending it.

Categories: Sergey Beryozkin

[OT] The best T-shirt I've seen at Apache Con EU 2014

Sergey Beryozkin - Sun, 11/23/2014 - 23:07
This is the first post about Apache Con EU 2014 held in beautiful Budapest I've been lucky to attend to.

One of the nice things about being an ApacheCon visitor is that one can see lots of cool T-shirts. The official T-shirts (I do treasure them) and other T-shirts with some great lines or digits printed on them. The T-shirts that many software geeks would be happy to wear. And indeed the visitors at ApacheCon EU 2014 had a lot of different T-shirts to demonstrate.

It was at the presentation about TomEE that I realized that while the rest of the room were glued to the presentation screen and being impressed by what TomEE could do I was looking at the T-shirts of TomEE experts doing the presentation and thinking how unfair it was I did not have a T-shirt like that too.

You can see Romain wearing it here.

Tomitribe, the company which did it right once again :-) !

Categories: Sergey Beryozkin

Apache Syncope 1.2 tutorial - part IV

Colm O hEigeartaigh - Thu, 11/13/2014 - 17:19
This is the fourth and final post in a series of articles on Apache Syncope 1.2. The previous tutorial looked at some new features relating to the Schema in Apache Syncope 1.2. This post will look at the REST API of Syncope and how it can be queried. We will also look at the new JAAS LoginModule for Apache Syncope that has been developed in Apache Karaf.

1) REST API of Apache Syncope

Apache Syncope features a rich REST API powered by Apache CXF. It is available via the URI "/syncope/rest/". Note that Apache Syncope 1.1 featured two REST APIs, one powered by Spring and another by Apache CXF, which was a refactoring of the former based on RESTful best practices. The Spring based API has been dropped in Apache Syncope 1.2, and only the CXF based API is now available via the "/syncope/rest" URI. Here are some example REST GET URIs for the "User" service in Syncope 1.2, that you can try out in a browser:
  • syncope/rest/users.json - get a list of all users in JSON format
  • syncope/rest/users - get a list of all users in an XML format
  • syncope/rest/users/self - get the authenticated user
Apache Syncope 1.2 uses the WADL generation capabilities of Apache CXF to expose the REST API as a WADL document. This can be accessed by adding "?_wadl" to the URI, for example "syncope/rest/?_wadl":

This document can be converted to HTML, see here for an example for Apache Syncope. Another new feature of the REST API in Apache Syncope 1.2 is support for FIQL. This allows you to easily search for users or roles matching a certain expression. For example:
  • syncope/rest/users/search?_s=lastLoginDate=ge=2014-11-13 - Search for the users who have logged in since 20014/11/13.
  • syncope/rest/users/search?_s=surname==smith - Search for the users with surname 'smith'.

2) JAAS LoginModule for Syncope

In a previous blog post written about the REST API of Apache Syncope, I gave detailed of a github project with some CXF based testcases. The tests showed how a CXF service could use Apache Syncope to authenticate a WS-Security UsernameToken presented by a client (as well as HTTP/BA). In addition, some other tests asked Syncope for the roles associated with the user, and enforced access to the service depending on the result. This github project has now moved to a new location here, and the tests have been updated to use the correct URLs for Apache Syncope 1.2.

In addition, a new test is added that shows how to use the new JAAS LoginModule for Syncope for authentication and authorization. The SyncopeLoginModule was developed for use in Apache Karaf, but can be used in others containers as well. In the testcase, the CXF JAASAuthenticationFeature is set on the service bus, which selects the "karaf" JAAS realm by default. The JAAS configuration file for the test is simply:

karaf {
    org.apache.karaf.jaas.modules.syncope.SyncopeLoginModule required

See Jean-Baptiste Onofré's blog for a further description of how to set up and test the SyncopeLoginModule.
Categories: Colm O hEigeartaigh

Meet the CXF team at ApacheCon EU

Sergey Beryozkin - Wed, 11/12/2014 - 13:45
ApacheCon EU will be held next week in Budapest, the nice capital of Hungary, and a number of my Talend and CXF colleagues will be there talking about CXF, Fediz, Syncope.

Please check the schedule.

Apache will be starting celebrating its 15th anniversary at the conference too, it is amazing that the organization is  relatively young, I thought it has been around for much longer given how popular and visible Apache is.

It is going to be exciting though I'm already getting a bit nervous as I usually do when I'm about to present :-).

Here is some information about the presentations I will do.

The first one is called JAX-RS 2.0 with Apache CXF Continued - I did a similar presentation in Denver in April and hence it has a "Continued" in the title but I'd like to confirm it is not a copy and paste of the original presentation, I tried to rework the slides and update the examples. Check the link and see if it can be of interest - I will talk about JAX-RS, JAX-RS 2.0, with plenty of code examples to be shown along the way.

The second one is called From OAuth1 to OAuth2 with Apache CXF and Hawk. I hope people who are interested in OAuth will find the presentation being entertaining enough. Note it will not be about "OAuth2 being not good enough, Hawk is to the rescue till OAuth3 arrives", nothing like that. The presentation will be about the extensibility of OAuth2, while giving the due credit to OAuth1 and indeed Hawk which can serve as a neat bridge for OAuth1 developers wondering if it makes sense to move to OAuth2 or not. The latest OAuth2 Proof-Of-Possession (POP) effort will be briefly described too.

See you at the conference !

Categories: Sergey Beryozkin

Apache Syncope 1.2 tutorial - part III

Colm O hEigeartaigh - Mon, 11/10/2014 - 17:59
This is the third in a series of articles on the new features of Apache Syncope 1.2. The first article covered installing Syncope using the new UI installer. The second article demonstrated some new features of Apache Syncope 1.2 when working with backend resources, namely the ability to synchronize and propagate encrypted passwords. This post focuses on some new features associated with schemas in Syncope 1.2.

Apache Syncope uses the concept of a schema to define attributes for User, Roles and Memberships (the relationship of a User with a Role). You can define the attribute name, the type, whether it is multi-valued, whether it is unique or read-only, whether it is stored internally or remotely, etc. There are three new interesting features in Syncope 1.2 in the area of Schemas:
  • Configuration Schema: The Configuration parameters are now covered by the Schema. You can add new attributes for the Configuration section in the Schema section.
  • Encrypted Schema attributes: A new "Encrypted" attribute type is available. This will ensure that Syncope always keeps the attribute value encrypted with the specified key.
  • Binary Schema attributes: A new "Binary" attribute type is available.
We will now focus on this latter feature. We will show how to use binary attributes with two examples. Start Apache Syncope + set up the LDAP Connector + Resource as covered in the first two tutorials.

1) Import X.509 Certificates into Syncope

The first use-case for binary schema attributes is to allow the synchronization of X.509 Certificates into Syncope from a backend resource. Go to the "Schema" tab, and create a new "User" attribute called "certificate" of type "Binary", and with mime type "application/x-x509-user-cert":

Next, go into the LDAP Resource configuration and add a new user mapping from the "certificate" attribute of the "UserSchema" to the LDAP "userCertificate" attribute. Now make sure that you have a user in your LDAP backend with a "userCertificate" attribute defined as follows:

Finally, run the synchronization task in Syncope. The user now has the certificate added as an attribute, which can be downloaded or else retrieved via the REST API:

2) Import images into Syncope

Another common use-case for binary attributes is to import images into Syncope. Create a new binary User attribute in the Schema called "image" of type "image/jpeg", and a new User mapping for the LDAP Connector mapping it to the LDAP "jpegPhoto" attribute. Assuming that a user in the LDAP backend has such an attribute defined, the newly synchronized User will look like this:

Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part II

Colm O hEigeartaigh - Fri, 11/07/2014 - 17:32
The previous tutorial on the new features of Apache Syncope 1.2 showed how to use the new UI installer to deploy Apache Syncope to Apache Tomcat, using MySQL for persistent storage. Last year we covered how to import users (and roles) from backend resources such as a database or a directory. An important new feature of Apache Syncope 1.2 is the ability to import non-cleartext passwords into Syncope when synchronizing from backend resources (and also the ability to propagate non-cleartext passwords to resources). The default behaviour is to hash the password according to the global configuration parameter 'password.cipher.algorithm' (defaults to SHA-1). This is problematic if the password is already hashed, as user authentication via the Syncope REST API will then fail.

1) Create policies in Apache Syncope

The first step is to start Apache Syncope and to create some policies for account and password creation, as well as synchronization. Start Syncope and go to the Configuration tab. Select "Policies" and create new "global" policy types for both "Account", "Password" and "Synchronization", with some sensible default values.

2) Synchronizing non-cleartext passwords from Apache Derby.

This is an update from the previous blog entry on importing users from Apache Derby using Syncope 1.1. Follow step 1 "Creating a Schema attribute" and step 2 "Apache Derby" in the previous blog. However, in section 2.b, rather than adding users with plaintext passwords, use the following user value instead when creating a table:

INSERT INTO USERS VALUES('dave', '8eec7bc461808e0b8a28783d0bec1a3a22eb0821', 'true', 'yellow');

Instead of using a plaintext password value, the second field is the SHA-1 encoded value of "security". In section 3.a "Define a Connector", it is necessary to change the "Password cipher algorithm" value from "CLEARTEXT" to "SHA1". In step 3.b "Define a Resource", it is necessary to specify an external attribute for the Username mapping of "NAME". Finally, in step 3.c "Create a synchronization task", use the "DBSyncPasswordActions" action class. This class treats the password retrieved from the table as encoded according to the "Password cipher algorithm" parameter of the Connector ("SHA1" in this case), and to store it directly in Syncope without subsequently hashing it again, which is what would happen for the plaintext case. Note that the presumption is that the (hashed) password is HEX encoded in the table.

After executing the synchronization task, then start a browser and navigate to "http://localhost:8080/syncope/rest/users/self", logging on as "dave" and "security".

3) Synchronizing non-cleartext passwords from Apache DS.

This is an update from the previous blog entry on importing users and roles from an LDAP backend such as Apache DS into Apache Syncope 1.1. Follow the first step in the previous tutorial to set up Apache DS and import users and groups. Add some users, e.g. "colm", this time with a SHA-256 encoded password. Importing users with encoded passwords from LDAP is a bit more sophisticated than the DB case above, because individual users can have different digest algorithms with the LDAP synchronization case, whereas all users must have the same digest algorithm for the DB synchronization case.

Start up Syncope, and follow the steps given in the previous tutorial to create a new connector and resource. The only difference with Syncope 1.2 is that you need to specify the external attribute for both the Username and Rolename mapping ("cn" in both cases for this example). Finally, create the Synchronization task as per the previous tutorial. However this time add both the LDAPPasswordSyncActions and LDAPMembershipSyncActions classes as "Actions classes". Finally execute the task, and check to see if the users + roles were imported successfully into Syncope. You can then log on via
"http://localhost:8080/syncope/rest/users/self" using any of the users imported from Apache DS, regardless of the internal cipher algorithm that was used.
Categories: Colm O hEigeartaigh

Apache Syncope 1.2 tutorial - part I

Colm O hEigeartaigh - Thu, 11/06/2014 - 13:26
Apache Syncope is a powerful and flexible open source tool to manage and orchestrate user identities for the enterprise. Last year, I wrote a series of four tutorials on Apache Syncope. The first covered how to create an Apache Syncope project, how to set up a MySQL database for internal storage, and how to deploy Apache Syncope to Apache Tomcat. The second covered how to import user identities and attributes from a database (Apache Derby) into Syncope. The third covered how to import users and roles from an LDAP backend (Apache DS) into Syncope. Finally, the fourth tutorial covered the REST API of Apache Syncope, as well as a set of Apache CXF-based testcases to demonstrate how to use the REST API of Apache Syncope for authentication and authorization.

This will be the first post in a new set of tutorials for Apache Syncope, with a focus on updating the previous set of tutorials (based on Syncope 1.1) with some updated features and new functionality that is available in the recently released 1.2.0 release. In this post we will cover how to use the new UI installer for creating a Apache Syncope project and deploying it to a container. This tutorial can be viewed as a more user-friendly alternative to the first tutorial of the previous series. Please also see the Syncope documentation on using the installer.

1) Set up a database for Internal Storage

The first step in setting up a standalone deployment of Apache Syncope is to decide what database to use for Internal Storage. Apache Syncope persists internal storage to a database via Apache OpenJPA. In this article we will set up MySQL, but see here for more information on using PostgreSQL, Oracle, etc. Install MySQL in $SQL_HOME and create a new user for Apache Syncope. We will create a new user "syncope_user" with password "syncope_pass". Start MySQL and create a new Syncope database:

  • Start: sudo $SQL_HOME/bin/mysqld_safe --user=mysql
  • Log on: $SQL_HOME/bin/mysql -u syncope_user -p
  • Create a Syncope database: create database syncope; 

2) Set up a container to host Apache Syncope

The next step is to figure out in what container to deploy Syncope to. In this demo we will use Apache Tomcat, but see here for more information about installing Syncope in other containers. Install Apache Tomcat to $CATALINA_HOME. Now we will add a datasource for internal storage in Tomcat's 'conf/context.xml'. When Syncope does not find a datasource called 'jdbc/syncopeDataSource', it will connect to internal storage by instantiating a new connection per request, which carries a performance penalty. Add the following to 'conf/context.xml':

<Resource name="jdbc/syncopeDataSource" auth="Container"
    testWhileIdle="true" testOnBorrow="true" testOnReturn="true"
    validationQuery="SELECT 1" validationInterval="30000"
    maxActive="50" minIdle="2" maxWait="10000" initialSize="2"
    removeAbandonedTimeout="20000" removeAbandoned="true"
    logAbandoned="true" suspectTimeout="20000"
    timeBetweenEvictionRunsMillis="5000" minEvictableIdleTimeMillis="5000"
    username="syncope_user" password="syncope_pass"

Uncomment the "<Manager pathname="" />" configuration in context.xml as well. The next step is to enable a way to deploy applications to Tomcat using the Manager app. Edit 'conf/tomcat-users.xml' and add the following:

<role rolename="manager-script"/>
<user username="manager" password="s3cret" roles="manager-script"/>

Next, download the JDBC driver jar for MySQL and put it in Tomcat's 'lib' directory. As we will be configuring a connector for a Derby resource in a future tutorial, also download the JDBC driver jar for Apache Derby and put it in Tomcat's 'lib' directory as well.

3) Run the Installer

Download and run the installer via 'java -jar syncope-installer-1.2.0-uber.jar'. You need to enter some straightforward values such as the installation path of the project, the Apache Maven home directory, the groupId/artifactId of the project, the directories where logs/bundles/configuration are stored.

Next, select "MySQL" as the database technology from the list, and give "syncope_user" and "syncope_pass" as the username + password, or whatever you have configured earlier when setting up MySQL. Select "Tomcat" as the application server (make sure the 'syncopeDataSource' is checked), and enter values for the address, port, manager username and password:

The installer will then create a Apache Syncope project + deploy it to Tomcat:

When the installer has finished, startup a browser and go to "localhost:8080/syncope-console", logging in as "admin/password". You should see the following:

Categories: Colm O hEigeartaigh

Security semantics of SAML SubjectConfirmation methods in Apache WSS4J/CXF

Colm O hEigeartaigh - Mon, 11/03/2014 - 17:27
A recent blog post covered two new security advisories issued for Apache CXF in relation to SAML tokens. In particular, one advisory dealt with the enforcement of the security semantics of SAML SubjectConfirmation methods when used with the TransportBinding:
There are different security requirements associated with SAML
SubjectConfirmation methods. These security requirements are not properly enforced in Apache CXF when used with the TransportBinding, leaving endpoints that rely on SAML for authentication vulnerable to types of spoofing attacks.In this post I will recap the security requirements that are associated with SAML SubjectConfirmation methods in the latest CXF releases:
  • Holder-of-Key: If the subject confirmation method is "holder-of-key", there must be some proof-of-possession of the key associated with the subject of the assertion. CXF will enforce that either the key was used to sign some portion of the SOAP request, or alternatively the subject credential of the SAML Assertion must match a client certificate credential when TLS with client authentiction is used.
  • Sender-Vouches: If the subject confirmation method is "sender-vouches", then CXF will enforce that the SAML Assertion and SOAP Body are signed by the same signature. Alternatively, it will check that TLS with client authentication is used.
  • Bearer: The SAML Assertion must be signed (with an internal XML Signature) by default. This can be configured in the latest WSS4J releases.
In addition, the SamlAssertionValidator in WSS4J now enforces that at least one of the standard SubjectConfirmation methods (as listed above) is present. It is also possible to specify a given SubjectConfirmation method that is required.
Categories: Colm O hEigeartaigh

Using Apache JMeter to load test Apache CXF endpoints

Colm O hEigeartaigh - Fri, 10/31/2014 - 18:32
Apache JMeter is a graphical tool that can be used to load-test your web applications. I created a new project in my github repo that creates a web application with a number of CXF endpoints, as well as a JMeter configuration file that can be used to load test the endpoints. The benefit of doing this kind of testing is to figure out how responsive various (security) protocols might be under load. In addition, the project uncovered a couple of threading issues surrounding policy handling, which were fixed by Dan Kulp in CXF 3.0.1.

The endpoints that are exposed in the application are:
  • /doubleit/services/doubleitnosecurity - No security at all. This can be used to test throughput over plaintext and TLS.
  • /doubleit/services/doubleittransport - This uses a Transport binding with a UsernameToken supporting token. The UsernameToken is just validated by a simple CallbackHandler on the service side. 
  • /doubleit/services/doubleitsymmetric - This uses a Symmetric binding with a UsernameToken supporting token. The UsernameToken is just validated by a simple CallbackHandler on the service side. 
  • /doubleit/services/doubleitsymmetricstreaming - This is the same as per the symmetric case above, except that it uses the new streaming WS-Security implementation available in Apache CXF 3.0.0. 
  • /doubleit/services/doubleitasymmetric - This uses a Asymmetric binding. Authentication is established by a certificate chain. 
  • /doubleit/services/doubleitasymmetricstreaming - Same as for the asymmetric case above, except that it uses the new streaming WS-Security implementation available in Apache CXF 3.0.0. 
Simply build the project with "mvn clean install" and drop the resulting .war file into your container (e.g. Apache Tomcat). Then start up JMeter + import the configuration file and run the tests.

    Categories: Colm O hEigeartaigh

    JSR-370: Even Better JAX-RS on the way

    Sergey Beryozkin - Thu, 10/30/2014 - 11:29
    No doubt JAX-RS 2.0 (JSR-339) has been, is and will be a success - a lot has been written  about the top features JAX-RS 2.0 offers. It is still very much a relevant story for many developers who have their REST services being migrated to JAX-RS 2.0, it is not always easy for a given production to switch to a new specification's API fast.

    But JAX-RS 2.0 is not the end of JAX-RS as such. So the fact JSR-370 (JAX-RS 2.1) is now active is a very good news for all of us working with or interested in JAX-RS.
    Have a look at the "Request" section and check the list of the improvements and new features that the specification will cover. Good stuff. Note the effort will be made to have JAX-RS applications much better prepared for supporting Web-based UI frontends. Another thing to note is the fact it will be Java 8 based so expect Java 8 features making themselves visible in JAX-RS 2.1 API, Marek and Santiago will come up with some very cool API ideas.

    All is great in the JAX-RS space. Explore it and enjoy !

    Categories: Sergey Beryozkin

    Two new security advisories for Apache CXF

    Colm O hEigeartaigh - Fri, 10/24/2014 - 20:10
    Two new security advisories have been released for Apache CXF, please see the CXF security advisories page for the details:
    • CVE-2014-3623: Apache CXF does not properly enforce the security semantics of SAML SubjectConfirmation methods when used with the TransportBinding
    • CVE-2014-3584: Apache CXF JAX-RS SAML handling is vulnerable to a Denial of Service (DoS) attack
    If you are using SAML SSO or else SAML tokens with the WS-SecurityPolicy Transport binding you should upgrade to either CXF 2.7.13 or 3.0.2.
    Categories: Colm O hEigeartaigh

    Apache CXF Authentication and Authorization test-cases IV

    Colm O hEigeartaigh - Thu, 10/23/2014 - 16:36
    This is the fourth in a series of posts on authentication and authorization test-cases for web services using Apache CXF. The first focused on different ways to authenticate and authorize UsernameTokens for JAX-WS services. The second looked at more advanced examples such as using Kerberos, WS-Trust, XACML, etc. The third looked at different ways of achieving SSO in CXF for both JAX-WS and JAX-RS services. This post gives some examples of authenticating and authorizing JAX-RS services in Apache CXF. I also included the SSO examples relevant to JAX-RS from the previous post. The projects are:
    • cxf-jaxrs-xmlsecurity: This project shows how to use XML Signature (and Encryption) to secure JAX-RS services. In particular, see the AuthenticationTest.
    • cxf-jaxrs-sts: This project demonstrates how to use HTTP/BA for authentication for JAX-RS, where the credentials are dispatched as a UsernameToken are dispatched to an STS instance for authentication. In addition, the project shows how to authorize the request by asking the STS for a SAML Token containing the roles of the user.
    • cxf-kerberos: This project (covered previously for JAX-WS) has been updated with a test that shows how to use Kerberos with JAX-RS.
    • cxf-saml-sso: This project shows how to leverage SAML SSO with Apache CXF to achieve SSO for a JAX-RS service. CXF supports the POST + redirect bindings of SAML SSO for JAX-RS endpoints. As part of this demo, a mock CXF-based IdP is provided which authenticates a client using HTTP/BA and issues a SAML token using the CXF STS. Authorization is also demonstrated using roles embedded in the issued SAML token. 
    • cxf-fediz-federation-sso: This project shows how to use the new CXF plugin of Apache Fediz 1.2.0 to authenticate and authorize clients of a JAX-RS service using WS-Federation. This feature will be documented more extensively at a future date, and is considered experimental for now. Please play around with it and provide feedback to the CXF users list.
    Categories: Colm O hEigeartaigh

    Apache CXF Fediz 1.1.2 released

    Colm O hEigeartaigh - Wed, 10/22/2014 - 12:32
    Apache CXF Fediz 1.1.2 has been released. Apache CXF Fediz is a Single Sign-On (SSO) solution based on the WS-Federation Passive Requestor Profile. It consists of an Identity Provider (IdP) which leverages the Apache CXF STS to issue tokens, as well as a number of container-specific plugins (Jetty, Tomcat, Spring, etc.) to enable SSO for web applications. The issues fixed in the new release include an upgrade to CXF 2.7.13, support for claims mapping in the STS, kerberos authentication support in the IdP, amongst other fixes.
    Categories: Colm O hEigeartaigh

    Kerberos Credential Delegation support in Apache CXF

    Colm O hEigeartaigh - Tue, 10/21/2014 - 15:25
    Apache CXF provides full support for integrating Kerberos with JAX-WS and JAX-RS services. A previous tutorial (here and here) described how to set up Kerberos with WS-Security in CXF, where the client obtains a Kerberos service ticket and encodes it in the security header of the request, and where it is validated in turn by the service. In this post we will discuss support for kerberos credential delegation for JAX-WS clients and services in Apache CXF. For more information on using kerberos with JAX-RS please consult the CXF documentation.

    1) Kerberos Client Configuration

    CXF provides a number of JAX-WS properties that can be used to configure Kerberos on the client side (documented here under "Kerberos Configuration Tags"). Essentially there are two different ways of doing it. The client must explicitly allow kerberos credential delegation by setting a property.

    1.1) Create and configure a KerberosClient Object directly

    The KerberosClient in the CXF WS-Security runtime module is used to retrieve a kerberos ticket. It can be configured by setting various properties and then referenced via the JAX-WS property:
    • ws-security.kerberos.client - A reference to the KerberosClient class used to obtain a service ticket.
    The "requestCredentialDelegation" property of the KerberosClient must be set to "true" to allow credential delegation. Here is an example in Spring:

    <bean class="" id="kerberosClient">
            <constructor-arg ref="cxf"/>
            <property name="contextName" value="bob"/>
            <property name="serviceName" value=""/>
            <property name="requestCredentialDelegation" value="true"/>

    <jaxws:client name="{service}port" createdFromAPI="true">
                <entry key="ws-security.kerberos.client" value-ref="kerberosClient"/>

    1.2) Use JAX-WS properties to configure Kerberos

    Rather than use the KerberosClient above, it is possible to configure Kerberos via JAX-WS properties:
    • ws-security.kerberos.jaas.context - The JAAS Context name to use for Kerberos.
    • ws-security.kerberos.spn - The Kerberos Service Provider Name (spn) to use.
    • - Whether the Kerberos username is in servicename form or not.
    • ws-security.kerberos.use.credential.delegation - Whether to use credential delegation or not in the KerberosClient.
    • ws-security.kerberos.request.credential.delegation - Whether to request credential delegation or not in the KerberosClient.
    The latter property must be set to "true" on the client side to allow kerberos credential delegation.

    2) Kerberos Service Configuration

    A JAX-WS service validates a kerberos ticket received in the security header of a request via a KerberosTokenValidator. Here is an example:

    <bean id="kerberosValidator"
            <property name="contextName" value="bob"/>
            <property name="serviceName" value=""/>
    <jaxws:endpoint ...>
                <entry key="ws-security.bst.validator" value-ref="kerberosValidator"/>
    3) Using Kerberos Credential Delegation

    After a service has validated a kerberos token sent by the client, it can obtain another kerberos token "on behalf of" the client, assuming the client enabled credential delegation in the first place. To use the client credential for delegation the "useDelegatedCredential" property of the KerberosClient must be set to "true" (see here), or else the JAX-WS property "ws-security.kerberos.use.credential.delegation" must be set to "true" if not configuring Kerberos via the KerberosClient Object.

    To see how a concrete use-case for this functionality, take a look at the KerberosDelegationTokenTest in the CXF STS advanced systests. Here we have a backend service which requires a SAML Token issued by an STS. However, the clients only know how to obtain a Kerberos token. So we have an intermediary service which requires a Kerberos token. The clients enable credential delegation + send a ticket to the Intermediary. The Intermediary validates the ticket, then uses it to obtain a Kerberos token "OnBehalfOf" the client, which in turn is used to authenticate to the STS + retrieve a SAML Token, which is then forwarded on to the backend service.
    Categories: Colm O hEigeartaigh


    Subscribe to Talend Community Coders aggregator