Integrating with the Jetty "openid" module

Overview

This guide provides details on configuration of the Curity Identity Server working in conjunction with the openid module to protect an application running in Jetty.

The openid module functions as an OpenID Connect Relying Party (RP) and enables authentication against an OpenID Connect Provider, in this case Curity.

The module is configured to protect an application and with that requires a token in order for access to be granted. If no session is available the module will redirect to the Curity Identity Server for authentication and if successful, grant a token. The token is then used to gain access to the protected application(s).

Claims from the token are passed to the protected application and are checked against the configuration in order for access to be granted.

Prerequisites

• An installation of the Curity Identity Server
• A configured client as outlined by this tutorial Code Flow
• An Authenticator that the Client can use, see this tutorial for an example Username Password Authenticator

If you do not have an installation of the Curity Identity Server, follow this tutorial installation of the Curity Identity Server and configure the installation by running Curity Basic Setup Wizard as outlined in this tutorial Curity Basic Setup Wizard.

Configure openid module

Enabling the Module

To enable the module run the following command from your JETTY_BASE directory:

java -jar {JETTY_HOME}/start.jar --add-to-start=openid

This will enable the module and create the file start.d/openid.ini, in which you'll find the configuration for this module.

Module Configuration

The OpenID Connect client is configured in start.d/openid.ini. The table below outlines some of the parameters. You can find more details in the documentation.

openid.ini example snippet

jetty.openid.provider=https://idsvr.example.com/oauth/v2/oauth-anonymous
jetty.openid.clientId=demo-client
jetty.openid.clientSecret=Secret12

Jetty configuration

The OpenID Connect authentication method has to be enabled in the WEB-INF/web.xml configuration file of your website. Add the following to the configuration:

<login-config>
    <auth-method>OPENID</auth-method>
    <realm-name>https://idsvr.example.com/oauth/v2/oauth-anonymous</realm-name>
</login-config>

<context-param>
    <param-name>org.eclipse.jetty.security.openid.error_page</param-name>
    <param-value>/error</param-value>
</context-param>

<security-constraint>
    <web-resource-collection>
      <web-resource-name>Some Protected Resource</web-resource-name>
      <url-pattern>/protected</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>**</role-name>
    </auth-constraint>
</security-constraint>

The <realm-name> value should equal the issuer value configured in the ini file.

With the <security-constraint> you can define which paths of your application should allow only authenticated users. By defining <role-name>**</role-name> you tell Jetty to allow users with any role, but they have to be authenticated.

Client configuration in the Curity Identity Server

The client registered in Curity need to have a proper redirect URI registered so that the OIDC flows work properly. Jetty's openid module uses the path /j_security_check for the callback. So, if your application is deployed on https://my-app.example.com, add the following to the allowed redirect URIs for your client: https://my-app.example.com/j_security_check.

Also remember that the client should be able to request at least the openid scope.

Conclusion

With Jetty's openid module and the Curity Identity Server you can quickly secure your web applications with the powerful OpenID Connect flows. No additional modifications on the Curity side are needed to make this mechanism work.