Jetty can be configured to handle the server load more efficiently by changing the default ThreadPool queue size as shown below:

Edit the following file


MIN_THREADS and MAX_THREADS should be chosen appropriately. For more details read

I see a blatant misconception, confusion and lack of understanding of the two widely used open standards for web : OAuth and OpenID , that I am compelled to write this blog and hopefully clear some doubts. 

What is OpenID ?

Taken directly from the official OpenID website

OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.

With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password, so you don’t need to worry about an unscrupulous or insecure website compromising your identity


Why invent OpenID?

Have you ever decided not to use the services on a website just because they were asking you to create a profile, choose a username and password, validate your email , and so on ? Well, you are not alone. Creating thousands and accounts and remembering username/password on each of them is a nightmare, not just from manageability perspective but also from security. Most users will end up choosing the same username/password for each account. So when one of their accounts gets hacked it is easy enough for attacker to hack other accounts. Even for the websites, managing user accounts introduces a lot of overhead. Not only they must allocate resources for managing user data but also ensure their passwords are stored securely. It seems like going through a lot of trouble, considering that most websites are only interested in basic user information such as their first name, last name , date of birth and email address - something that can be easily inferred from user's profile on social website such as Google,Yahoo,etc.

OpenID is a win-win for everybody. Users can use their existing accounts without sharing their password with third-party websites. They can choose what information they would like to share. The websites don't manage user accounts, they don't have to validate email addresses and can  concentrate on the business purpose they are serving.

How does it work?

Let's assume your OpenID provider is Google. The following excerpt is directly taken from their website.

This image illustrates the following steps.

                 1.The web application asks the end user to log in by offering a set of log-in options, including Google Apps accounts.
                 2.The user selects to sign in using a Google Apps account.
                 3.The web application performs discovery as defined in the documentation to find location of the XRDS document.
                 4.Google returns an XRDS document, which contains the Google Apps (hosted) domain endpoint address.
                 5.The web application sends a login authentication request (optionally with OAuth parameters) to the provided endpoint address.
                 6.This action redirects the user to a Google Apps account Federated Login page.
                 7.The user signs into their Google Apps account. Google Apps then displays a confirmation page and asks the user to confirm or reject a set of authentication requests by the web application. If the web application is using OpenID+OAuth, the user is also asked to approve access to a specific set of Google Apps services.
Note: In some circumstances the login step or the approval step (or both) may be skipped.

                 8.If the user approves the authentication, Google returns the user to the web application, and supplies a persistent, opaque identifier that the application can use to recognize the user. For OpenID+OAuth, an authorized request token is also returned.
                 9.The web application uses the Google-supplied identifier to recognize the user and allow access to application features and data. For OpenID+OAuth, the web application uses the request token to continue the OAuth sequence (at step 7) and gain access to the user's Google Apps services.


Although this workflow is somewhat Google specific but the same applies for any other OpenID provider.

What is OAuth?

OAuth is an open standard for authorization. It allows client applications to request access to resources hosted on a resource server on behalf of resource owners.With regards to OAuth it is important to understand following roles:


A resource can be anything from user information, pictures,files, services, etc.

Resource Server

The server hosting resources that are owned by the user and protected by OAuth.

Resource Owner

Typically the user of an application who owns the resources. He is the one who can grant access to client application for accessing his resources.

Client App

An application making API request to the resource server to access user's resources.

Authorization Server

The server responsible for authentication the user and granting client application privilege(token) to access resource server if approved by the user


OAuth is best explained with an example:

I am assuming you already have a Facebook account , and if not let's just pretend you have one. All information that you put there , your profile information, your pictures, your post belong to you. You own your data. Facebook also lets you set privacy rules allowing you to decide who you want to share your information with. Hence, you are the resource owner and Facebook is your resource server.

Now, if I was developing a social application, say FriendSight, that provides users with unique insights about their friends, I would need access to user's data from Facebook. In doing so I face following challenges :

  • How do I get user's data from Facebook  without asking for their Facebook credentials?
  • How can I expect users to trust my application with their information?
  • How does Facebook know I am an application that should be trusted?

OAuth2 addresses each of the concerns mentioned above. If I implemented OAuth2 in my application , the flow of my application would be as follows :

Step 1: Register FriendSight with Facebook

First, I need to register my application with Facebook by filling up a form and providing some basic information, more importantly the URL where it needs to redirect users in the login process. Once I register successfully, Facebook will issue a cleint id and client secret for my application. This piece of information is required to identify client applications to the authorization servers.

Step 2 : Seek user's permission to access their Facebook account

Users are not required to hand over their Facebook credentials. Instead, they will be redirected to Facebook's website where they will see a familiar login window

In this example, Facebook is both the Authorization Server as well as the Resource Server. In real word though they can be different. OAuth does not describe how both of them should communicate with each other, leaving the choice of implementation to the developers.


Step 3:  After successfully login in, the user is asked to authorize FriendSight

The user can choose what information he wants to allow. He can be sure that only that much information and no more will be provided by Facebook to Client App.


Step 4: User is redirected back to FriendSight

Behind the scenes , FriendSight has obtained an authorization token from Facebook. This token encapsulates all permissions user has granted which will let it communicate with Facebook API


When to use what ?

 If you are considering using one of these technology in your application your decision should be based on the use-case. The following table describes some of the usage scenarios :



I want to provide federated login in my application. I only need access to basic

profile information such as name, dob and email address


Yes. Although its meant for authorization, in the process user also gets authenticated.

The role of Resource Server is diminished in this use-case.

I want to provide federated login in my application but I don't want to spend too much

time and effort trying to figure out the technology. Also, I don't expect to register my application with

the Authorization Server.


Not recommended. OAuth2 requires Client App to register themselves with the Authorization Server. However, some Authorization Server may choose to accept anonymous Client Apps request

I want to access user's data hosted on a remote server. The user should be able to delegate proper access

to my application.




Comparing OAuth and OpenID is like comparing Apples with Oranges. They both serve very different purpose. One is for authentication whereas the other is for authorization. One is no more or less secure than the other. Which technology should you use is a question best answered by keeping in mind the usage scenario, complexity of the system and most importantly the technology supported by the Identity Providers or Authorization Servers.

There are a lot of standards for describing how security should be performed for SOAP based web-services but none when it comes to REST. Due to the lack of common standard , the developers building RESTful services are tasked with researching ways of securing them. There are plethora of options available , some more appealing than others and it is easy to get confused while choosing the right approach suited for your use-case. This blog post aims to provide a comparison of these techniques, their pros and cons and their applicability.

HTTP Basic Authentication

This is the most straightforward way of securing a REST service. The user credentials are supplied with each request in the "Authorization" header. The credential "username/password" is encoded and embedded in the HTTP header. Since it is encoded and not encrypted , for meaningful security the request should go over a secure channel using SSL.


  • Simple and easy to implement.
  • Must be used with SSL for meaningful security.
  • Must provide username/password with each request. Requires handling of naked user credentials.
  • No support for federated access using protocols such as Shibboleth,SSO, OpenID ,etc.

Adapting WS-Trust/Security to work with REST

WS-Trust/Security describes how federated authentication should be performed in web-services. A Security Token Service(STS) is responsible for issuing,validating and revoking security tokens for a  client application. The client must first obtain a token from STS before requesting the web-service. STS issues a security token (SAML) after validating the client credentials. This time sensitive token is presented by the client with each request to the web-service. The web-service validates this token by making a call to the STS. After receiving a positive response from the STS , the request is processed. The security token is embedded in the SOAP message header. 

The same model can be applied to work with REST. One thing to remember though is that with REST services there are always two classes of consumers : software programs and humans with web-browsers. If software programs are the only consumers of your REST services then this way of authentication can work just like with SOAP based services. But with humans this approach is not very friendly i.e it is not practical to assume that a human will manually authenticate himself to a STS , obtain a security token and present it to the web-service every time he wishes to use it.


  • Consistent Standards based approach to secure web-service be it SOAP or REST.
  • Federated Access with STS.
  • Doesn't require handling of user credentials.
  • Setup requires deploying a separate Security Token Service configured against an Identity Provider
  • Significant overhead involved in obtaining/validating token with each request.

API Keys

In this technique a unique API key is generated for each user. This key has a limited lifetime during which it is associated with the user and his permissions to access the service. Typically a user shall sign-up for an API-key to access the service. The system-admin reviewing the application may decide to accept or reject the applicant , and assign permissions if accepted. The key is valid until it expires.

It is possible to incorporate a federated access , by letting users sign-up for the key using their institution's credential with  Shibboleth , SSO or OpenID and then assigning them a unique key. This decoupling ensures that users need to use their own credential while accessing the RESTful services , and relieving the services from handling user credentials themselves.

  • Simple to implement
  • Works well with Shibboleth,SSO, OpenID and other protocols for federated authentication.
  • Low overhead
  • More scalable than the other techniques.
  • Requires out of band mechanism for generating and managing API keys. Perhaps using some sort of an user portal where they sign-up for a key and receive an email notification when their application is approved.


The best example of API keys in action is Amazon's S3 REST Security. They use a concept of secret-key( much like api-key) , linked to the user's account , that is used to digitally sign each request(parameters) and generate a code. This code is passed along with the API call. The Amazon S3's server computes the code using the same secret-key and request parameters. If they match request is accepted otherwise denied.

Setup Amazon EC2 RDS — RDS Setup: User 'root' Password: 'password' Database: pacsdb Security Group: Same as EC2
From EC2 instance:
mysql -uroot -ppassword -h pacsdb
mysql> CREATE USER 'dicom'@'%' IDENTIFIED BY 'password';
mysql> grant all on pacsdb.* to 'dicom'@'%' identified by 'password';
mysql> \q
Now on EC2:
mysql -u dicom -ppassword -h pacsdb
Provide this info to DCM4CHEE