Colm O hEigeartaigh

Subscribe to Colm O hEigeartaigh feed
Colm O hEigeartaigh
Updated: 2 hours 36 min ago

SAML SSO RP Metadata support in Apache CXF

Thu, 05/28/2015 - 17:28
Apache CXF provides comprehensive support for SSO using the SAML Web SSO profile for CXF-based JAX-RS services. In Apache CXF 3.1.0 (and 3.0.5), a new Metadata service is available to allow for the publishing of SAML SSO Metadata for a given service.

The MetadataService class is available on a "metadata" path and provides a single @GET method that returns the service metadata in XML format. It has the following properties which should be configured:
  • String serviceAddress - The URL of the service
  • String assertionConsumerServiceAddress - The URL of the RACS. If it is co-located with the service, then it can be the same URL as for the serviceAddress.
  • String logoutServiceAddress - The URL of the logout service (if available).
  • boolean addEndpointAddressToContext - Whether to add the full endpoint address to the values configured above. The default is false.
In addition, the MetadataService extends the AbstractSSOSpHandler, which contains various properties that are required to sign the metadata (keystore alias, crypto properties file which references the keystore, etc.). A sample spring-based configuration for the MetadataService is available in the CXF system tests here. Here is the sample output when accessed via a web brower:

Categories: Colm O hEigeartaigh

Apache CXF 3.1.0 released

Tue, 05/26/2015 - 16:04
Apache CXF 3.1.0 has been released and is available for download. The migration guide for CXF 3.1.x is available here. The main (non-security) features of CXF 3.1.0 are as follows:
  • Java 6 is no longer supported.
  • Jetty 9 is now supported. Support for Jetty 7 has been dropped.
  • A new Metrics feature for collecting metrics about CXF services is available. 
  • A new Throttling feature is available for easily throttling CXF services.
  • A new Logging feature is available that is more powerful than the existing logging functionality.
The security-specific changes and features are as follows:
  • CXF 3.1.0 picks up a new major release of WSS4J (2.1.0) and OpenSAML (3.1.0). Please see a recent post on WSS4J 2.1.0 for some migration notes if you are using WS-Security or SAML with CXF.
  • The STS now signs issued SAML tokens by default using RSA-SHA256 (previously RSA-SHA1).
  • Some security configuration tags have been renamed from "ws-security.*" to "security.*", as they are now shared with the XML Security JAX-RS module. The old tags will continue to work as before however without any change. See the Security Configuration page for more information.
  • The SAML/XACML functionality previously available in the cxf-rt-security module is now in a new cxf-rt-security-saml module.
  • A new Metadata service for SAML SSO is available. More on this in a future blog post.
  • It is now possible to "plug in" custom security policy validators for WS-Security in CXF, if you want to change the default validation logic. See here for a test that shows how to do this.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.0.4 released

Fri, 05/15/2015 - 16:24
In addition to the new major release of Apache WSS4J (2.1.0), there is a new bug fix release available - Apache WSS4J 2.0.4. Here are the most important bugs that were fixed in this release:
  • We now support the InclusiveC14N policy.
  • We can enforce that a Timestamp has an "Expires" Element via configuration, if desired.
  • There is a slight modification to how we cache signed Timestamps, to allow for the scenario of two Signatures in a security header that sign the same Timestamp, but with different keys.
  • The policy layer now allows a SupportingToken policy to have more than one token.
  • A bug has been fixed in the MerlinDevice crypto provider, which is designed to work with smartcards.
  • A bug has been fixed in terms of using the correct JCE provider for encryption/decryption.
Categories: Colm O hEigeartaigh

Apache WSS4J 2.1.0 released

Fri, 05/15/2015 - 16:23
A new major release of Apache WSS4J, 2.1.0, has been released. The previous major release of almost a year ago, Apache WSS4J 2.0.0, had a lot of substantial changes (see the migration guide), such as a new set of maven modules, a new streaming implementation, changes to configuration tags, package changes for CallbackHandlers, etc. In contrast, WSS4J 2.1.0 has a much smaller set of changes, and users should be able to upgrade with very few changes (if at all). This post briefly covers the new features and migration issues for WSS4J 2.1.0.

Here are the new features of WSS4J 2.1.0:
  • JDK7 minimum requirement: WSS4J 2.1.0 requires at least JDK7. The project source has also been updated to make use of some of the new features of JDK7, such as try-with-resources, etc.
  • OpenSAML 3.x support: WSS4J 2.1.0 upgrades from OpenSAML 2.x to 3.x (currently 3.1.0). This is an important upgrade, as OpenSAML 2.x is not currently supported.
  • Extensive code refactoring. A lot of work was done to make the retrieval of security results easier and faster.

Here are the migration issues in WSS4J 2.1.0:
  • Due to the OpenSAML 3.x upgrade, you will need to make a small change in your SAML CallbackHandlers, if you are specifying the "Version". In WSS4J 2.0.x, you could specify the SAML Version by passing a "org.opensaml.common.SAMLVersion" instance through to the SAMLCallback.setSamlVersion(...) method. The "org.opensaml.common" package is removed in OpenSAML 3.x. Instead, a new Version bean is provided in WSS4J 2.1.0, that can be passed to the setSamlVersion method on SAMLCallback as before. See here for an example.
  • The Xerces and xml-apis dependencies in the DOM code of Apache WSS4J 2.1.0 have been removed (previously they were at "provided" scope).
  • If you have a custom Processor instance to process a token in the security header in some custom way, you must add the WSSecurityEngineResult that is generated by the processing, to the WSDocInfo Object via the "addResult" method. Otherwise, it will not be available when security results are retrieved and processed.

Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.4 released

Wed, 04/22/2015 - 15:09
Apache Santuario - XML Security for Java 2.0.4 has been released. The issues fixed are available here. Perhaps the most significant issue fixed is an interop issue which emerged when XML Security is used with OpenSAML (see the Apache CXF JIRA where this was raised).
Categories: Colm O hEigeartaigh

Vulnerability testing of Apache CXF based web services

Mon, 04/13/2015 - 16:21
A number of automated tools can be used to conduct vulnerability or penetration testing of web services. In this article, we will take a look at using WS-Attacker to attack Apache CXF based web service endpoints. WS-Attacker is a useful tool based on SOAP-UI and developed by the Chair of Network and Data Security, Ruhr University Bochum ( and 3curity GmbH ( As an indication of how useful this tool is, it has uncovered a SOAP Action Spoofing vulnerability in older versions of CXF (see here). In this testing scenario, WS-Attacker 1.4-SNAPSHOT was used to test web services using Apache CXF 3.0.4. Apache CXF 3.0.4 is immune to all of the attacks described in this article (as can be seen from the "green" status in the screenshots).

1) SOAPAction Spoofing attacks

A SOAPAction spoofing attack is where the attacker will attempt to fool the service by "spoofing" the SOAPAction header to execute another operation. To test this I created a CXF based SOAP 1.1 endpoint which uses the action "soapAction="http://doubleit/DoubleIt"". I then loaded the WSDL into WS-Attacker, and selected the SOAPAction spoofing plugin, selecting a manual SOAP Action. Here is the result:

2) WS-Addressing Spoofing attacks

A WS-Addressing Spoofing attack involves sending an address in the WS-Addressing ReplyTo/To/FaultTo header that is not understood or known by the service, but to which the service redirects the message anyway. To guard against this attack in Apache CXF it is required to ensure that the WS-Addressing headers should be signed. As a sanity test, I added an endpoint where WS-Addressing is not configured, and the tests fail as expected:

3) XML Signature wrapping attacks

XML Signature allows you to sign various parts of a SOAP request, where the parts in question are referenced via an "Id". An attacker can leverage various "wrapping" based attacks to try to fool the resolution of a signed Element via its "Id". So for example, an attacker could modify the signed SOAP Body of a valid request (thus causing signature validation to fail), and put the original signed SOAP Body somewhere else in the request. If the signature validation code only picks up the Element that has been moved, then signature validation will pass even though the SOAP Body has been modified.

For this test I created a number of endpoints that are secured using WS-SecurityPolicy. I captured a successful signed request from a unit test and loaded it into WS-Attacker, and ran the Signature wrapping attack plugin. Here is the result:

4) Denial of Service attacks

A Denial of Service attack is where an attacker attempts to crash or dramatically slow down a service by flooding it with data, or crafting a message in such a way as to cause parsing to crash or hang. An example might be to create an XML structure with a huge amount of Attributes or Elements, that would cause an out of memory error. WS-Attacker comes with a range of different attacks in this area. Here are the results of all of the DoS attacks against a plain CXF SOAP service (apart from the SOAP Array attack, as the service doesn't accept a SOAP array):

Categories: Colm O hEigeartaigh

New Apache WSS4J and CXF releases

Fri, 02/20/2015 - 17:37
Apache WSS4J 2.0.3 and 1.6.18 have been released. Both releases contain a number of fixes in relation to validating SAML tokens, as covered earlier. In addition, Apache WSS4J 2.0.3 has unified security error messages to prevent some attacks (see here for more information). Apache CXF 3.0.4 and 2.7.15 have also been released, both of which pick up the recent WSS4J releases.
Categories: Colm O hEigeartaigh

Unified security error messages in Apache WSS4J and CXF

Mon, 02/16/2015 - 17:59
When Apache WSS4J encounters a error on processing a secured SOAP message it throws an exception. This could be a configuration error, an invalid Signature, incorrect UsernameToken credentials, etc. The SOAP stack in question, Apache CXF for the purposes of this post, then converts the exception into a SOAP Fault and returns it to the client. However the SOAP stack must take care not to leak information (e.g. internal configuration details) to an attacker. This post looks at some changes that are coming in WSS4J and CXF in this area.

The later releases of Apache CXF 2.7.x map the WSS4J exception message to one of the standard error QNames defined in the SOAP Message Security Profile 1.1 specification. One exception is if a "replay" error occurred, such as if a UsernameToken nonce is re-used. This type of error is commonly seen in testing scenarios, when messages are replayed, and returning the original error aids in figuring out what is going wrong. Apache CXF 3.0.0 -> 3.0.3 extends this functionality a bit by adding a new configuration option:
  • - Whether to return the security error message to the client, and not one of the default error QNames. Default is "false".
However, even returning one of the standard security error QNames can provide an "oracle" for certain types of attacks. For example, Apache WSS4J recently released a security advisory for an attack that works if an attacker can distinguish whether the decryption of an EncryptedKey or EncryptedData structure failed. There are also attacks on data encrypted via a cipher block chaining (CBC) mode, that only require the knowledge about whether the specific decryption failed.

Therefore from Apache WSS4J 2.0.3 onwards (and CXF 3.0.4 onwards) a single error fault message ("A security error was encountered when verifying the message") and code ("", "SecurityError") is returned on a security processing error. It is still possible to set "" to "true" to return the underlying security error to aid in testing etc.
Categories: Colm O hEigeartaigh

Two new security advisories released for Apache WSS4J

Tue, 02/10/2015 - 12:47
Two new security advisories have been released for Apache WSS4J, both of which were fixed in Apache WSS4J 2.0.2 and 1.6.17.
  • CVE-2015-0226: Apache WSS4J is (still) vulnerable to Bleichenbacher's attack
  • CVE-2015-0227: Apache WSS4J doesn't correctly enforce the requireSignedEncryptedDataElements property
Please see the Apache WSS4J security advisories page for more information.
Categories: Colm O hEigeartaigh

New SAML validation changes in Apache WSS4J and CXF

Tue, 02/03/2015 - 18:27
Two new Apache WSS4J releases are currently under vote (1.6.18 and 2.0.3). These releases contain a number of changes in relation to validating SAML tokens. Apache CXF 2.7.15 and 3.0.4 will pick up these changes in WSS4J and enforce some additional constraints. This post will briefly cover what these new changes are.

1) Security constraints are now enforced on SAML Authn (Authentication) Statements

From the 1.6.18 and 2.0.3 WSS4J releases, security constraints are now enforced on SAML 2.0 AuthnStatements and SAML 1.1 AuthenticationStatements by default. What this means is that we check that:
  • The AuthnInstant/AuthenticationInstant is not "in the future", subject to a configured future TTL value (60 seconds by default).
  • The SessionNotOnOrAfter value for SAML 2.0 tokens is not stale / expired.
  • The Subject Locality (IP) address is either a valid IPv4 or IPv6 address.
2) Enforce constraints on SAML Assertion "IssueInstant" values

We now enforce that a SAML Assertion "IssueInstant" value is not "in the future", subject to the configured future TTL value (60 seconds by default). In addition, if there is no "NotOnOrAfter" Condition in the Assertion, we now enforce a TTL constraint on the IssueInstant of the Assertion. The default value for this is 30 minutes.

3) Add AudienceRestriction validation by default

The new WSS4J releases allow the ability to pass a list of Strings through to the SAML validation code, against which any AudienceRestriction address of the assertion are compared. If the list that is passed through is not empty, then at least one of the AudienceRestriction addresses in the assertion must be contained in the list. Apache CXF 3.0.4 and 2.7.15 will pass through the endpoint address and the service QName by default for validation (for JAX-WS endpoints). This is controlled by a new JAX-WS security property:
  • ws-security.validate.audience-restriction: If this is set to "true", then IF the SAML Token contains Audience Restriction URIs, one of them must match either the request URL or the Service QName. The default is "true" for CXF 3.0.x, and "false" for 2.7.x.
Categories: Colm O hEigeartaigh

LDAP support in Apache Camel

Wed, 01/28/2015 - 17:29
Apache Camel allows you to add LDAP queries to your Camel routes via the camel-ldap and camel-spring-ldap components. The camel-ldap component allows you to perform an LDAP query using a filter as the message payload. The spring-ldap component is a wrapper for Spring LDAP, and is a bit more advanced than the camel-ldap component, in that it also supports the "bind" and "unbind" operations, in addition to "search".

I've created two test-cases that show how to use each of these components. Both test-cases use the Camel file component to read in files that contain LDAP queries. These queries are then dispatched to an Apache DS server that is configured via annotations in the test code, using an LDIF file containing some test data. The results are then processed and written out in the target directory. The test-cases are available here
Categories: Colm O hEigeartaigh

Apache Santuario - XML Security for Java 2.0.3 and 1.5.8 released

Mon, 01/19/2015 - 16:53
Versions 2.0.3 and 1.5.8 of Apache Santuario - XML Security for Java have been released. Version 2.0.3 contains a critical security advisory (CVE-2014-8152) in relation to the new streaming XML Signature support introduced in version 2.0.0:
For certain XML documents, it is possible to modify the document and the streaming XML Signature verification code will not report an error when trying to validate the signature.

Please note that the "in-memory" (DOM) API for XML Signature is not affected by this issue, nor is the JSR-105 API. Also, web service stacks that use the streaming functionality of Apache Santuario (such as Apache CXF/WSS4J) are also not affected by this vulnerability.Apart from this issue, version 2.0.3 contains a significant performance improvement, and both releases contain minor bug fixes and dependency upgrades.
Categories: Colm O hEigeartaigh

XML Advanced Electronic Signature (XAdES) support in Apache Camel

Wed, 01/14/2015 - 12:43
I have previously covered some XML Signature and Encryption testcases in Apache Camel. Camel 2.15 will feature some new limited support for XML Advanced Electronic Signatures (XAdES) in the XML Security component. This post will briefly cover what XML Advanced Electronic Signatures are, and show how they can be produced in Camel. No support exists yet for validating XAdES Signatures in Camel. Note that as Camel 2.15 is not yet released, some of the details are subject to change.

XML Signature has a number of shortcomings in terms of conveying meta-data describing the signing process to the recipient. It does not include the signing certificate/key in the signature itself. It does not tell the recipient when or where the signature was created, which role the signer had at the time of signing, what format the signed data is in, what the signature policy was, etc. XAdES attempts to solve these problems by introducing standard properties that are inserted into the "Object" part of an XML Signature. Some of these properties are then included in the message signature.

Camel 2.15 will support XAdES in the XML Security component by a new "properties" configuration option, which must reference a XAdESSignatureProperties implementation. I added a new test to the camel-xmlsecurity project in github that illustrates how to do this. The spring configuration for the test is here. The xmlsecurity route links to a DefaultXAdESSignatureProperties implementation, which is configured with the signing key (and alias), an "Implied" Signature policy, and a role of "employee". The resulting ds:Object in the XML Signature looks like:

  <etsi:QualifyingProperties xmlns:etsi="..." Target="#...">
    <etsi:SignedProperties Id="_1c03790b-8e46-4837-85bc-d6562e4c713c"> 
              <ds:DigestMethod Algorithm="...#sha256"/>
Categories: Colm O hEigeartaigh

Signing and encrypting Apache Camel routes

Mon, 01/12/2015 - 16:02
A recent blog post looked at using the XML Security component and dataformat in Apache Camel to sign and encrypt XML documents. However, what if you wish to secure non-XML data? An alternative is to use the Apache Camel Crypto component and dataformat. The Crypto component provides the ability to sign (and verify) messages (using the JCE). Similarly, the Crypto dataformat allows you to encrypt (and decrypt) messages (again using the JCE). Another alternative is to use the PGPDataFormat, which allows you to use PGP to sign/encrypt Camel messages.

I have created a github project called "camel-crypto" with some samples about how to use these features. It contains the following tests:
The tests follow a similar pattern, where they take some (XML) data, sign/encrypt it, and copy it to a particular directory. Another route then takes the secured data, and verifies/decrypts it, and copies it to another directory. The tests also show how to use the Camel Jasypt component to avoid hard-coding plaintext passwords in the spring configuration files. The tests rely on a SNAPSHOT version of Camel (2.15-SNAPSHOT) at the time of writing this post, due to some fixes that were required (particularly in terms of adding new (Spring) configuration options to the PGPDataFormat).
Categories: Colm O hEigeartaigh

New SSL/TLS vulnerabilities in Apache CXF

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

XML Security using Apache Camel

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

Apache Syncope 1.2 tutorial - part IV

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

Apache Syncope 1.2 tutorial - part III

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

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

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