Integrating with the Jetty "openid" module

Integrating with the Jetty "openid" module

tutorials

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 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.

ParameterDescriptionExample
jetty.openid.providerThe URL identifying the Provider, in this case, the Curity Identity Server. This is also known as the Issuer ID. You can find this value for your instance of the Curity Identity Server in the admin UI, in the info pane on the General tab of your OAuth Profiles.https://idsvr.example.com/oauth/v2/oauth-anonymous/
jetty.openid.provider.authorizationEndpointThe authorization endpoint URL. Set this only if you’ve disabled exposing metadata in Curity.https://idsvr.example.com/oauth/v2/oauth-authorize
jetty.openid.provider.tokenEndpointThe token endpoint URL. Set this only if you’ve disabled exposing metadata in Curity.https://idsvr.example.com/oauth/v2/token
jetty.openid.clientIdThe ID of the client registered in the Curity Identity Server.demo-client
jetty.openid.clientSecretThe secret of the client registered in the Curity Identity Server.Secret12
jetty.openid.scopesComma-separated list of additional scopes (apart from openid) that should be requested during authorization.profile,email
jetty.openid.sslContextFactory.trustAllSet this to true to ease development, so that self-signed certificates are accepted. Remember not to change this setting in production!true

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.

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Keep up with our latest articles and how-tos using RSS feeds