The OpenID Connect standard is launched

OpenID Connect is an official standard as of today. The specification was approved after voting by the OpenID Foundation and this marks the completion of the long and laboursome process to design and specify a new single sign-on (SSO) protocol for the Internet based on the successful OAuth 2.0 framework.

We began development of an OpenID Connect server for enterprises in early 2012 and want to thank everyone on the Connect, OAuth and JOSE workgroups for contributing to the standard and providing us with guidance on the many questions that we faced as we worked on the SDK and the Connect2id server.

The official announcement can be read on the foundation’s website.

Online demo of our OpenID Connect client and server

Today we put up an online demo of the Connect2ID server along with a generic OpenID Connect client. With that we wish to show the capabilities of the new internet standard for single sign-on (SSO) based on the successful OAuth 2.0 framework. OpenID Connect is designed to sign users onto web as well as native apps and also provides a standard extensible schema for provisioning user details (called UserInfo) such as email, name and contact information to client applications.

The OpenID Connect 1.0 specification is expected to become final in spring of 2014. Around the same time we prepare to release our Connect2ID server for business customers.


You can test the OpenID Connect login by going to


Just click on “Login with OpenID Connect” and when you’re redirected to the IdP server enter “alice” + “secret” as credentials.


The consent screen will display which scope and claim values are requested, also the remembered values which the user (can also be implicitly) has previously agreed to. The login page logic is built entirely in JavaScript, so its interaction with the Connect2ID server integration APIs can be examined by testers and developers. A production login page will of course have this logic in the backend and can have a different UI design for obtaining the user’s credentials and consent. The server API also enables integration of arbitrary authentication factors, such as hardware tokens or biometrics.


Upon returning to the OpenID Connect client you should see the process of decoding the authentication response, making the token request, verifying the ID token and extracting its content, and finally the UserInfo request being made. The client was built with our open source OAuth 2.0 SDK with OpenID Connect extensions.

The demo Connect2ID server is set to remember user sessions for 15 minutes, so if you come back to it within that time you will be redirected straight to the consent form.

The OpenID Connect client has also two other tabs – “Provider details” and “Client details” where you can configure it to speak to another public OpenID Connect server (IdP). We intend to add more OpenID Connect request options to the client UI in future.

Finding the most efficient Java ObjectOutput method for strings

Coding distributed services and apps often calls for marshalling Java objects into a binary form that can be streamed over the network. Infinispan, for example, requires objects to be serialised so they can be multicast to the nodes of the data grid.

The standard Java serialisation implementation packs a lot of object data in order to be able to automatically reproduce an object upon deserialisation. Devising your custom serialiser can save a lot of bytes, as the following snippet demonstrates:

// Serialise a date object
Date now = new Date();

// As object
ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutput oout = new ObjectOutputStream(bout);
System.out.println("Date writeObject length: " + bout.toByteArray().length);

// As long representation
bout = new ByteArrayOutputStream();
oout = new ObjectOutputStream(bout);
System.out.println("Date writeLong length: " + bout.toByteArray().length);

Running the above code produces the following result:

Date writeObject length: 46
Date writeLong length: 14

Amazing, converting the Date object to its long representation results in a three-fold saving. For every 1 million transmitted Date objects that means a difference of 32 Mbytes.

The conclusion is clear: custom serialisers make sense. They can reduce network traffic and speed up the overall responsiveness of your distributed service or app.

Developers are typically given the standard DataOutput interface to implement their custom serialisers. This is true for Infinispan, JBoss Marshalling, and probably other frameworks too. Use of the DataOutput interface is straightforward – you just have to pick the correct method for the data type that you wish to marshal. For serialising strings, however, there are three methods provided:

  • DataOutput.writeUTF(String)
  • DataOutput.writeBytes(String)
  • DataOutput.writeChars(String)

Let’s find out which one is the most efficient:

String s = "The quick brown fox jumps over the lazy dog";

ByteArrayOutputStream bout = new ByteArrayOutputStream();
ObjectOutput oout = new ObjectOutputStream(bout);
System.out.println("writeUTF length: " + bout.toByteArray().length);

bout = new ByteArrayOutputStream();
oout = new ObjectOutputStream(bout);
System.out.println("writeBytes length: " + bout.toByteArray().length);

bout = new ByteArrayOutputStream();
oout = new ObjectOutputStream(bout);
System.out.println("writeChars length: " + bout.toByteArray().length);

bout = new ByteArrayOutputStream();
oout = new ObjectOutputStream(bout);
System.out.println("writeObject length: " + bout.toByteArray().length);

Running the above produces the following:

writeUTF length: 51
writeBytes length: 49
writeChars length: 92
writeObject length: 50

The writeUTF and writeBytes methods output similar byte lengths. Surprisingly so does writeObject. This could be due to Java treating strings in writeObject in a optimised way. writeChars however produces a byte output that is almost twice as long.

The conclusion is that for strings you could use any of the available methods, but stay clear of writeChars.

Happy coding! 🙂

OpenID Connect – Как да си върнем личната идентичност в мрежата

Листовете от презентацията ми на PlovdivConf 2013, където разказах за проблемите на удостоверяването в интернет в настоящето и как новият OpenID Connect протокол дава път за тяхното разрешаване в бъдеще, посредством функциите Discovery/WebFinger и Self-Issued.


OpenID-Connect-Identity-Slides [OpenOffice presentation]

OpenID-Connect-Identity-Slides [PDF]

Encrypt and you shall be protected, says Snowden

From Edward Snowden’s Q&A session at the Guardian:

Q: Is encrypting my email any good at defeating the NSA survelielance? Id my data protected by standard encryption?

Snowden: Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.

One more good reason to use the Nimbus library for JavaScript Object Signing and Encryption (JOSE+JWT) 🙂

CORS Filter 1.7 with more configuration options

CORS FilterThe Java servet filter for enabling CORS (cross-domain) web applications received a major upgrade today.

Up until now in order to change the out-of-the-box CORS configuration you had to add filter init-params in the web.xml descriptor of your application. A number of developers asked for alternative configuration means, such as specifying a properties file for the configuration. This is now supported.

The CORS Filter will now apply the following precedence when resolving the configuration:

  1. Checks for an environment variable “cors.configurationFile” pointing to a properties file with the CORS configuration.
  2. Checks for a servlet filter init-param “cors.configurationFile” pointing to a properties file with the CORS configuration.
  3. Checks for CORS params in filter init section, applies the default values if not found.

Another important configuration change is the ability to specify a general “allow-any-request-header” policy by setting the cors.supportedHeaders to an asterisk.

Handling of same-domain requests that carry a redundant Origin header (set by some Javascript frameworks) is fixed too.

Thanks to David Bellem, Stijn Cremers and Casey Lucas for initiating this new release of the CORS Filter. Also thanks to Anne van Kesteren for answering my CORS-related query on the W3C list.

Лаб Пловдив – учредителен протокол

*** Протокол на учредителната среща на Лаб Пловдив ***

16 май 2013, Арт Кафе Пловдив

записал Владимир Джувинов

Срещата започна в 18:30ч с лично представяне на всеки от участниците.

След това бяха записани предложения на участници за лаба за неговите условия,
организиране и дейности:

* Възможност за сигурно паркиране на велосипеди
* Лесно паркиране в района за автомобили
* Тиха стая за работа
* Достъп 24/7
* Нежилищно, тихо място
* Възможност за помещаване на фриланс офиси, място за работни срещи и с
клиенти, за презентации
* Климатизация
* WC
* Вендинг машина напитки, кафе, вафли
* Провеждане на демонстрации, хакер маратони
* Варианти за достъп: с чип карта, за всички членове или за основно
пребиваващите в лаба, които да отварят на членове без карта/ключ
* Заключващи се шкафчета за лични вещи, компютри
* Постоянни PC машини за общо ползване
* Вътрешен правилник
* Тераса
* Интернет

Определени бяха следните етапи в създаването на лаба:

Етап 1: покриване на минималното нужно за неговото функциониране

1. Помещение, минимално обзаведено
2. Интернет
3. Вътрешен правилник
4. Кът за трапезария

Етап 2: след заработване и установяване на лаба

1. Създаване на юридическо лице – Сдружение с нестопанска цел
2. Провеждане и огранизиране на платени курсове, презентации и събития за
допълнително финансиране на лаба

Членство и членски внос

Дефинирани бяха две възможни форми на членуване в лаба:

1. Общи членове на лаба: Достъп до лаба 24/7, свободно ползване на общата
база на лаба (т.н. hackerspace), възможност за достъп на външни лица с
придружител член.

2. Членове на лаба ползващи го като собствен офис: със собствено обособено
и запазено място (бюро) за работа. Могат евентуално да имат собствена една
или повече отделни стаи в лаба.

След гласуване с обикновено мнозинство бяха взети следните решения:

1. Лаб Пловдив да има както общ хакер-спейс (за всички членове) така и
обособено работно пространство за членове, които да го ползват като техен
постоянен офис (co-worker спейс).

2. Месечен членски внос от 25лв за общите членове на лаба.

3. Месечен членски внос от 100лв за членове на лаба, които ще го ползват като
офис и ще имат обособено място за работа там. Техни фирмени сътрудници ще
могат да ползват намаление, чиито размер не беше решен.

4. Месечен членски внос от 10 лв за ученици.

Извърши се преброяване изявилите желание да бъдат членове:

1. Като общи членове с 25 лв месечен членски внос: 30 човека
2. Като общи членове ученици с 10 лв месечен членски внос: 2 човека
3. Като фрийлансъри с 100 лв месечен членски внос за офис място: 5 човека

След преброяването беше съставен списък с имената и телефонните номера на
желаещите да бъдат членове.

Проведе се дискусия за управлението и общото събрание на лаба.

Бяха дефинирани следните екипи, след което за участие тях се записаха

* Екип за избор на място на лаба
* Екип за създаване на правилник
* Екип за създаване и поддръжка на сайт на лаба
* Екип за маркетинг
* Касиер, също за плащане на сметки
* Секретар, за водене на протоколи и документация
* Домакин(и) на лаба
* Екип за техническа поддръжка
* Екип за организиране на събития и курсове
* Екип за набиране на партньори и спонсори

Решено беше следващата среща да се проведе на същото място (Арт Кафе) на 22 май
от 18:30ч. На нея желаещите да бъдат членове да носят двойния размер на
месечния членски внос за заплащане на първоначалната такса. Ще се обсъдят
предложени места за лаба, правилник и ще бъдат гласувани отговорници за

Срещата приключи в 21:30ч с бира 🙂

CORS Filter 1.6 supports any URI scheme

CORS FilterThe Java CORS Filter for adding Cross-Origin Resource Sharing to existing web apps received an important update to permit any URI scheme, not just the ubiquitous http:// and https:// as originally supported. This change is in line with RFC 6454 which defines the concept of web origins.

This means that now you can also service CORS requests for “custom” schemes as app://, fb:// , etc.

The new CORS Filter release should reach Maven Central later today. You can also get it from the CORS Filter Git repo at Bitbucket.

Cheers to Edraí Brosa for initiating this important change!


All JSON-RPC 2.0 libraries are now in Maven Central

masthead-jsonrpc2baseThe migration from Ant to Maven is now complete and all Java libraries for handling JSON-RPC 2.0 messages are now published in Maven Central.

You can find them under the groupId:

The useful JSON-RPC 2.0 Shell tool, available for purchase, has also been completely mavenised. It has found a lot of use in Android development recently and there have been plans to add HTTP basic authentication support to it (via a prompt).

JSON-RPC 2.0 libraries and tools switch to Maven

masthead-jsonrpc2baseThe Java libraries and tools for JSON-RPC 2.0 message serving and processing now use Apache Maven to build.

Migrating the previous Apache Ant scripts took about a day a to complete and was not without hassles, notable the ZIP package distribution and the automatic versioning of JavaDocs. We’ll now be able to gain from Maven’s automatic dependency resolution and I have gained enough knowledge to begin considering myself a Maven power user 🙂

The following related JSON-RPC 2.0 projects also got a Maven make-over:

Publishing to Maven Central is on the to-do list complete now 🙂