diff --git a/Client-configuration.md b/Client-configuration.md index 67500ba..cd26b87 100644 --- a/Client-configuration.md +++ b/Client-configuration.md @@ -22,27 +22,27 @@ By default all valid users get a special Spring Security GrantedAuthority that i To map these authorities into more useful ones like **ROLE_USER** and **ROLE_ADMIN**, you need to wire in an authorities mapper, such as the one included in the client library: -``` - - - - - - - - - - - - +```xml + + + + + + + + + + + + ``` # Filter There is one filter class `org.mitre.openid.connect.client.OIDCAuthenticationFilter` that handles all core client (or "Relying Party") functions. It is set to listen on `/openid-connect-login` at the root of the application. The filter bean is configured like this: -``` +```xml @@ -71,22 +71,11 @@ It is configurable for use in different modes through the use of different prope * `authRequestOptionsService`: Provides a set of optional parameter values to be sent to the authorization endpoint * `authRequestUrlBuilder`: Crafts the URL used to redirect the user to the OpenID Connect server -### Validator - -To validate ID token signatures, the client will need access to a validator for each issuer's key set. This service bean will automatically fetch the keys and set up a validator: - -``` - -``` - -Depending on how the component scan is set up in the project, the validator may need to get set up as a property on the filter: - -``` - -``` ## Issuer Service +This service tells the client which `issuer`, or root server URL, to talk to for a login request. + ### Static Issuer Service Always returns the same issuer, very useful for tightly-coupled deployments. @@ -101,7 +90,7 @@ Always returns the same issuer, very useful for tightly-coupled deployments. Allows an issuer to be passed in following the format of the OpenID Connect [third party client login initiation protocol](http://openid.net/specs/openid-connect-standard-1_0.html#client_Initiate_login). If the issuer is not passed in the `iss` parameter, it will redirect the user to an [Account Chooser](https://github.com/mitreid-connect/account-chooser) URL and listen for the callback. -``` +```xml @@ -110,31 +99,31 @@ This service supports setting of a `whitelist` or a `blacklist` property. If the The whitelist is a set of strings: -``` - - - http://good-idp.com/ - http://other-idp.com/ - - +```xml + + + http://good-idp.com/ + http://other-idp.com/ + + ``` The blacklist is a set of a strings: -``` - - - http://bad-idp.com/ - http://evil-idp.com/ - - +```xml + + + http://bad-idp.com/ + http://evil-idp.com/ + + ``` ### Webfinger Discovery Issuer Service Takes in input from a user form and does discovery based on the Webfinger protocol. The filter will redirect the user to a login page (to be supplied by the client application) if an identifier is not returned as a result of this discovery. -``` +```xml @@ -144,58 +133,58 @@ This service supports setting of a `whitelist` or a `blacklist` property. If the The whitelist is a set of strings: -``` - - - http://good-idp.com/ - http://other-idp.com/ - - +```xml + + + http://good-idp.com/ + http://other-idp.com/ + + ``` The blacklist is a set of a strings: -``` - - - http://bad-idp.com/ - http://evil-idp.com/ - - +```xml + + + http://bad-idp.com/ + http://evil-idp.com/ + + ``` ## Server Configuration -The client must know things about the server such as its authorization endpoint URL and token endpoint URL. Since these will vary from issuer to issuer, the server configuration objects are indexed by issuer URL. +In addition to the root `issuer` URL that uniquely identifies a server, a client must know things about the server such as its authorization endpoint URL and token endpoint URL. Since these will vary from issuer to issuer, the server configuration objects are indexed by issuer URL. ### Static Server Configuration Provides server information such as authorization endpoint url, issuer, and other parameters for each configured issuer configured as in-memory objects inside a map. -``` - - - - - - - - - - - - - - - +```xml + + + + + + + + + + + + + + + ``` ### Dynamically Discovered Server Configuration Dynamically discovers server information for an issuer based on the [OpenID Connect Discovery protocol](http://openid.net/specs/openid-connect-discovery-1_0.html). -``` +```xml ``` @@ -205,22 +194,22 @@ Server information is stored in an in-memory cache after discovery. Combines a static configuration service with a dynamically discovered one in one bean. Checks the static configuration first, then performs dynamic discovery. The `servers` property passes through to the static configuration service. -``` - - - - - - - - - - - - - - - +```xml + + + + + + + + + + + + + + + ``` ## Client Configuration @@ -231,33 +220,33 @@ The client must know certain things like its `client_id` and `client_secret` in Provides information for a pre-registered client to connect to a server. -``` - - - - - - - - - - openid - email - address - profile - phone - - - - - - http://localhost:8080/simple-web-app/openid_connect_login - - - - - - +```xml + + + + + + + + + + openid + email + address + profile + phone + + + + + + http://localhost:8080/simple-web-app/openid_connect_login + + + + + + ``` @@ -265,38 +254,38 @@ Provides information for a pre-registered client to connect to a server. Dynamically registers the client for each issuer based on the template of client information. -``` - - - - - - - openid - email - address - profile - phone - - - - - - http://localhost:8080/simple-web-app/openid_connect_login - - - - - +```xml + + + + + + + openid + email + address + profile + phone + + + + + + http://localhost:8080/simple-web-app/openid_connect_login + + + + + ``` -All properties set in the template object are passed in to the dynamic registration endpoint's input and the dynamically registered client information is held in an in-memory cache. +All properties set in the template object are passed in to the dynamic registration endpoint's input and the dynamically registered client information is held (by default) in an in-memory cache. #### Registered Client Service -This service has a `registeredClientService` property which optionally allows for a service to be configured to save a client's registration information. If the registration information is not saved somewhere, then a client application will re-register itself with the server every time it starts. By default, the service is configured with an `InMemoryRegisteredClientService` which, as the name suggests, does not use persistent storage and will therefore forget about existing registrations every time the client is restarted. The library also contains a `JsonFileRegisteredClientService` which saves the registered client's registration_client_uri and registration_access_token out to disk in a plaintext (non-encrypted) JSON file. This file contains sensitive information and it must be readable and writeable by whatever process is running the client application, but it should not be readable by other untrusted applications. +The dynamic client registration service has a `registeredClientService` property which optionally allows for a service to be configured to save a client's registration information. If the registration information is not saved somewhere, then a client application will re-register itself with the server every time it starts. By default, the service is configured with an `InMemoryRegisteredClientService` which, as the name suggests, does not use persistent storage and will therefore forget about existing registrations every time the client is restarted. The library also contains a `JsonFileRegisteredClientService` which saves the registered client's registration_client_uri and registration_access_token out to disk in a plaintext (non-encrypted) JSON file. This file contains sensitive information and it must be readable and writeable by whatever process is running the client application, but it should not be readable by other untrusted applications. -``` +```xml @@ -310,58 +299,58 @@ It would be greatly preferable for a client to have its own implementation of th Combines a static client configuration service with a dynamically registered one. Checks the static configuration first, and if that fails, invokes the dynamic registration process. The `clients` property passes through to the static service and the `template` and `registeredClientService` properties pass through to the dynamic service underneath. -``` - - - - - - - - - - openid - email - address - profile - phone - - - - - - http://localhost:8080/simple-web-app/openid_connect_login - - - - - - - - - - - - openid - email - address - profile - phone - - - - - - http://localhost:8080/simple-web-app/openid_connect_login - - - - - - - - - +```xml + + + + + + + + + + openid + email + address + profile + phone + + + + + + http://localhost:8080/simple-web-app/openid_connect_login + + + + + + + + + + + + openid + email + address + profile + phone + + + + + + http://localhost:8080/simple-web-app/openid_connect_login + + + + + + + + + ``` @@ -373,7 +362,7 @@ This optional service returns a `Map` of parameters and values t This service will return the same Map of options regardless of the context of the client, server, or request. It is configured by passing in a map of options and their values: -``` +```xml @@ -387,12 +376,13 @@ This service will return the same Map of options regardless of the context of th If no options service is configured, a static authorization request options service with an empty map is provided automatically. ## Authorization Request URL Builder +In order to direct the user to the authorization endpoint of the IdP, the client filter must create a URL to send to the user's browser. This is handled by the Authorization Request URL Builder service. ### Plain Authorization Request Builds the URL using normal HTTP parameters. -``` +```xml ``` @@ -400,48 +390,48 @@ Builds the URL using normal HTTP parameters. Builds the URL using a signed Request Object. -``` +```xml ``` -This also requires configuration (and generation) of a [json web key set](wiki/Keys) and several support components such as a signing and validation service and a keystore: +This also requires configuration (and generation) of a [json web key set](wiki/Key-generation) and several support components such as a signing and validation service and a keystore: -``` - - - - - - - - - +```xml + + + + + + + + + ``` Furthermore, the client must be configured to publish its public key at a URL that the server can fetch in order to validate the request object's signature. The following bean will publish whatever keys are configured in the signing and validation service that's used in the auth request builder: -``` - - - - +```xml + + + + ``` ### Encrypted Authorization Request Builds the URL using an encrypted Request Object. -``` +```xml - + - - + + - + ```