Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: formatting issues in dcr document #4119

Merged
merged 1 commit into from
Mar 10, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
206 changes: 122 additions & 84 deletions docs/admin/auth-server/endpoints/client-registration.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,15 +10,21 @@ tags:

### Dynamic Client Registration (DCR)

Dynamic client registration refers to the process by which a client submits a registration request to the Authorization server and how that request is served by the Authorization server. It is explained in the following specifications:
Dynamic client registration refers to the process by which a client submits a registration request to the Authorization
server and how that request is served by the Authorization server. It is explained in the following specifications:

1. For OpenID Connect relying parties - [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html).
1. For OAuth 2.0 client (without OpenID Connect features) - [OAuth 2.0 Dynamic Client Registration Protocol - RFC 7591](https://tools.ietf.org/html/rfc7591).
1. CRUD operations on client - [OAuth 2.0 Dynamic Client Registration Management Protocol - RFC 7592](https://tools.ietf.org/html/rfc7592).
1. [OpenBanking OpenID Dynamic Client Registration](https://openbanking.atlassian.net/wiki/spaces/DZ/pages/36667724/OpenBanking+OpenID+Dynamic+Client+Registration+Specification+-+v1.0.0-rc2#OpenBankingOpenIDDynamicClientRegistrationSpecification-v1.0.0-rc2-ClientRegistrationRequest)
- [For OpenID Connect relying parties](https://openid.net/specs/openid-connect-registration-1_0.html)
- [For OAuth 2.0 client (without OpenID Connect features)](https://tools.ietf.org/html/rfc7591)
- [Client management (CRUD) operations](https://tools.ietf.org/html/rfc7592)
- [OpenBanking OpenID Dynamic Client Registration](https://openbanking.atlassian.net/wiki/spaces/DZ/pages/36667724/OpenBanking+OpenID+Dynamic+Client+Registration+Specification+-+v1.0.0-rc2#OpenBankingOpenIDDynamicClientRegistrationSpecification-v1.0.0-rc2-ClientRegistrationRequest)

### Client Registration endpoint
The URI to dynamically register a client to a Janssen Auth Server can be found by checking the `registration_endpoint` claim of the OpenID Connect configuration reponse, typically deployed at `https://<my.jans.server>/.well-known/openid-configuration`
The URI to dynamically register a client to a Janssen Auth Server can be found by checking the `registration_endpoint`
claim of the OpenID Connect configuration reponse, typically deployed at

```text
https://<my.jans.server>/.well-known/openid-configuration
```

### Configuring Janssen AS to allow clients to dynamically register
The Janssen Authorization server will serve a DCR request if the following configuration parameters are set:
Expand All @@ -30,38 +36,45 @@ Configure the Janssen AS using steps explained in the [link](#curl-commands-to-c

### Client registration Requests

#### 1. A simple client registration request (with mandatory parameter):
```
curl -X POST -k -H 'Content-Type: application/json' -i 'https://my.jans.server/jans-auth/restv1/register' \
--data '{"redirect_uris": ["https://my.jans.client/page"]}'
```

#### 2. A typical client registration request :
A typical client registration request : A client or developer calls the client registration endpoint with a set of client metadata as specified in [RFC7591](https://www.rfc-editor.org/rfc/rfc7591.html#page-8)

```
curl -X POST -k -i 'https://my.jans.server/jans-auth/restv1/register' \
--data '{ \
"redirect_uris": ["https://client.example.org/cb"] \
"client_id": "c3BhdRkqfX", \
"client_secret": "bd136123eeffeef234235805d", \
"grant_types": ["authorization_code", "refresh_token"], \
"token_endpoint_auth_method": "client_secret_basic", \
"jwks_uri": "https://client.example.org/my_public_keys.jwks", \
"client_name": "My Example", \
"client_name#fr": "Mon Exemple" \
}' \
#### 1. A simple client registration request (with mandatory parameter)

```shell
curl -X POST -k -H 'Content-Type: application/json' -i 'https://my.jans.server/jans-auth/restv1/register' \
--data '{"redirect_uris": ["https://my.jans.client/page"]}'
```

#### 2. A typical client registration request

A client or developer calls the client registration endpoint with a set of client metadata as specified in [RFC7591](https://www.rfc-editor.org/rfc/rfc7591.html#page-8)

```shell
curl -X POST -k -i 'https://my.jans.server/jans-auth/restv1/register' \
--data '{ \
"redirect_uris": ["https://client.example.org/cb"] \
"client_id": "c3BhdRkqfX", \
"client_secret": "bd136123eeffeef234235805d", \
"grant_types": ["authorization_code", "refresh_token"], \
"token_endpoint_auth_method": "client_secret_basic", \
"jwks_uri": "https://client.example.org/my_public_keys.jwks", \
"client_name": "My Example", \
"client_name#fr": "Mon Exemple" \
}'
```
#### 3. Client Registration Request Using a signed request object

In some usecases like FAPI implementation, DCR request payload is a JWT.
Example:
```
curl -X POST -k -H 'Content-Type: application/jwt' \
-H 'Accept: application/json' \
-i 'https://my-jans-server/jans-auth/restv1/register' \
--data 'eyJraWQiOiJrWTIyZXBUT......ueOg2HkjpggwAEP84jq9Q'

Example:

```shell
curl -X POST -k -H 'Content-Type: application/jwt' \
-H 'Accept: application/json' \
-i 'https://my-jans-server/jans-auth/restv1/register' \
--data 'eyJraWQiOiJrWTIyZXBUT......ueOg2HkjpggwAEP84jq9Q'
```
When such will be the nature of client registration requests, the following configuration properties should be set in the authorization server:

When such will be the nature of client registration requests, the following configuration properties should be set in
the authorization server:

- `dcrSignatureValidationEnabled` - enables DCR signature validation
- `dcrSignatureValidationJwksUri` - specifies JWKS URI for all DCR's validations.
Expand All @@ -70,85 +83,110 @@ When such will be the nature of client registration requests, the following conf
Configure the Janssen AS using steps explained in the [link](#curl-commands-to-configure-jans-auth-server)

#### 4. Client registration using software statement
A signed assertion from a trusted party, a Software statement or Software Statement Assertion (SSA), is used to dynamically register clients to an Authorization server.

A signed assertion from a trusted party, a Software statement or Software Statement Assertion (SSA), is used to
dynamically register clients to an Authorization server.

Example:
```
#!/bin/bash curl -X POST https://my.jans.server/jans-auth/restv1/register \
-H "Content-Type: application/json" \
--data-binary @- <<DATA \
{ "redirect_uris": [ "https://client.example.org/cab1" ], \
"software_statement":"eyJ0eXAi........j3ouyeYOv8", \
"jwks_uri":"https://my.portal/portal/jwks" \
} DATA

```shell
curl -X POST https://my.jans.server/jans-auth/restv1/register \
-H "Content-Type: application/json" \
--data-binary @- <<DATA \
{ "redirect_uris": [ "https://client.example.org/cab1" ], \
"software_statement":"eyJ0eXAi........j3ouyeYOv8", \
"jwks_uri":"https://my.portal/portal/jwks" \
} DATA
```

For Client registrations using Software statements, the AS should be configured using the following configuration parameters:
To enable client registrations using Software statements, the AS should be configured using the following configuration
parameters:

- `softwareStatementValidationType` - The value of this variable is one of the following:
- NONE - validation is skipped for software statement
- SCRIPT - (default), invokes `getSoftwareStatementJwks` of dynamic registration script which has to return jwks.
- JWKS - claim name within software statement that has inlined JWKS
- JWKS_URI - claim name within software statement that points to JWKS URI that should lead to keys.
- `dcrSignatureValidationSoftwareStatementJwksURIClaim` - specifies claim name inside software statement that should point to JWKS URI.
- `dcrSignatureValidationSoftwareStatementJwksClaim` - specifies claim name inside software statement. Value of claim should point to inlined JWKS.
- `dcrSignatureValidationSoftwareStatementJwksURIClaim` - specifies claim name inside software statement that should
point to JWKS URI.
- `dcrSignatureValidationSoftwareStatementJwksClaim` - specifies claim name inside software statement. Value of claim
should point to inlined JWKS.

Configure the AS using steps explained in the [link](#curl-commands-to-configure-jans-auth-server)

#### 5. Special mention about FAPI:

In case of a typical [client registration request in FAPI implementation]( https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html), the request object which is a signed JWT (as seen in point 3) is also called an SSA (Software statement Assertion) or DCR payload. This SSA can contain the software_statement inside it which is also a signed JWT. Each of the JWTs, the outer JWT called the SSA and the inner JWT called the software_statement are signed by different entities - the TPP and OBIE respectively.
In case of a typical [client registration request in FAPI implementation]( https://openbankinguk.github.io/dcr-docs-pub/v3.3/dynamic-client-registration.html),
the request object which is a signed JWT (as seen in point 3) is also called an SSA (Software statement Assertion) or
DCR payload. This SSA can contain the software_statement inside it which is also a signed JWT. Each of the JWTs, the
outer JWT called the SSA and the inner JWT called the software_statement are signed by different entities - the TPP and
OBIE respectively.


### Security Pointers

If `dynamicRegistrationEnabled` is enabled in the Authorization Server, assess the following points to minimize potential exposure of sensitive personal data:
If `dynamicRegistrationEnabled` is enabled in the Authorization Server, assess the following points to minimize
potential exposure of sensitive personal data:

1. `trustedClientEnabled` and `dynamicRegistrationPersistClientAuthorizations` properties determine whether clients are trusted and if consent should be sought from the user before releasing their personal data to the RP
2. `dynamicRegistrationScopesParamEnabled` controls whether default scopes are globally enabled. If `dynamicRegistrationScopesParamEnabled` is `true` then scopes defined as default will be automatically added to any dynamically registered client entry without consent of OP's administrator. Therefore, make an informed decision before setting this field to `true`.
1. `trustedClientEnabled` and `dynamicRegistrationPersistClientAuthorizations` properties determine whether clients
are trusted and if consent should be sought from the user before releasing their personal data to the RP
2. `dynamicRegistrationScopesParamEnabled` controls whether default scopes are globally enabled.
If `dynamicRegistrationScopesParamEnabled` is `true` then scopes defined as default will be automatically added to any
dynamically registered client entry without consent of OP's administrator. Therefore, make an informed decision before
setting this field to `true`.

### CURL commands to configure Jans-auth server

Jans-auth server is configured using [Jans Config Api](https://github.com/JanssenProject/jans/tree/main/jans-config-api) :

1. Obtain the access token
```
curl -u "put_client_id_here:put_config_api_client_secret_here" https://<your.jans.server>/jans-auth/restv1/token \
-d "grant_type=client_credentials&scope=https://jans.io/oauth/jans-auth-server/config/properties.write"
```
2. Patch jans-auth server configurations to reflect `anExampleConfigField` with the value `anExampleConfigField_value`

```
curl -X PATCH -k -H 'Content-Type: application/json-patch+json' \
-i 'https://<your.jans.server>/jans-config-api/api/v1/jans-auth-server/config' \
-H "Authorization: Bearer put_access_token_here" --data '[
{
"op": "add",
"path": "anExampleConfigField",
"value": "anExampleConfigField_value"
}
]'
```
Example : Patch jans-auth server configurations to reflect `dynamicRegistrationEnabled` with value as `true`

```
curl -X PATCH -k -H 'Content-Type: application/json-patch+json' \
-i 'https://<your.jans.server>/jans-config-api/api/v1/jans-auth-server/config' \
-H "Authorization: Bearer put_access_token_here" --data '[
{
"op": "add",
"path": "dynamicRegistrationEnabled",
"value": "true"
}
]'
```
### Client metadata
#### Obtain the access token

```shell
curl -u "put_client_id_here:put_config_api_client_secret_here" https://<your.jans.server>/jans-auth/restv1/token \
-d "grant_type=client_credentials&scope=https://jans.io/oauth/jans-auth-server/config/properties.write"
```

#### Patch jans-auth server configurations

Patch jans-auth server configurations to reflect `anExampleConfigField` with the value `anExampleConfigField_value`

Command to obtain metadata schema:
```shell
curl -X PATCH -k -H 'Content-Type: application/json-patch+json' \
-i 'https://<your.jans.server>/jans-config-api/api/v1/jans-auth-server/config' \
-H "Authorization: Bearer put_access_token_here" --data '[
{
"op": "add",
"path": "anExampleConfigField",
"value": "anExampleConfigField_value"
}
]'
```

For example, to patch the jans-auth server configurations to reflect `dynamicRegistrationEnabled` with value as `true`

```shell
curl -X PATCH -k -H 'Content-Type: application/json-patch+json' \
-i 'https://<your.jans.server>/jans-config-api/api/v1/jans-auth-server/config' \
-H "Authorization: Bearer put_access_token_here" --data '[
{
"op": "add",
"path": "dynamicRegistrationEnabled",
"value": "true"
}
]'
```

### Client metadata

Command to obtain metadata schema

```shell
/opt/jans/jans-cli/config-cli.py --schema /components/schemas/Client
```

Output:
```

```json
{
"dn": "string",
"inum": "string",
Expand Down
1 change: 1 addition & 0 deletions docs/governance/triage.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,7 @@ These labels enrich issue/PR with metadata that will help during triage process
### Bot labeling methodology

The following labels are automatically assigned to Issues and PRs in GitHub following the schema provided in this [file](../../automation/github-labels/labels-schema.json).

| Label | Method |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `comp-<module>` | The bot will detect from the title the component between the parentheses. `feat(jans-auth-server): detect` will result in the label `comp-jans-auth-server` added to the issue or PR. In a PR these labels are also detected by modified files path |
Expand Down