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

[management] Add support for Dynamic Client Registration #1580

Closed
brasseld opened this issue Oct 16, 2018 · 7 comments

Comments

@brasseld
Copy link
Member

commented Oct 16, 2018

The purpose of this issue is to let the management-api invoke an OIDC endpoint to create OIDC client when creating a new application.

Application must support new field for redirect_uris (mandatory for DCR).

@n2ygk

This comment has been minimized.

Copy link

commented Apr 8, 2019

I imagine this is already well understood, but, in case it helps, here is what I would need in order to make this feature work with my OAuth2/OIDC AS (PingFederate 9.1 specifically but I assume any standard OIDC AS would work):

  • AS: Enable Dynamic Client Registration:
    • Configure the AS to require a Bearer Token with a specific scope (e.g. client_creator) for "dynamic provisioning clients" that are permitted to do so.
  • AS: Provision client credentials for the APIM provisioning client with restricted scope (client_creator)
  • APIM: use the client_id and client_secret from above with the Client Credentials flow to get an Access Token with that specific scope (client_creator).
  • APIM: POST to the OIDC registration_endpoint with header "Authorization: Bearer access_token" with a body something like this:
{
  "redirect_uris": [
    "http://localhost:8002",
  ],
  "client_name": "dynamic_client_3",
  "response_types": ["code", "token", "id_token"],
  "token_endpoint_auth_method": "client_secret_basic",
  "scope":"<list of restricted scopes>",
  "grant_types":[
    "authorization_code",
    "implicit"
  ],
  "logo_uri": "https://www.columbia.edu/content/themes/custom/columbia/favicon-crown.png"
}

and get a response like this:

{
    "client_id": "dc-vlq6aFt77gXd6MIpKSgkTH",
    "client_name": "dynamic_client_3",
    "redirect_uris": [
        "http://localhost:8002"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "grant_types": [
        "implicit",
        "authorization_code"
    ],
    "client_secret": "7UehninDtpifn1sID4OyMz",
    "client_secret_expires_at": 0,
    "logo_uri": "https://www.columbia.edu/content/themes/custom/columbia/favicon-crown.png",
    "scope": "<list of restricted scopes>",
    "response_types": [
        "code",
        "token",
        "id_token"
    ],
    "validate_using_all_eligible_atms": false,
    "refresh_token_rolling_policy": "server_default",
    "persistent_grant_expiration_type": "server_default",
    "grant_access_session_revocation_api": false
}

Notably, you cannot set the client_id or client_secret: they are automatically generated and associate with the client_name. And, those client names are not unique, so it would be up to APIM to keep track of the names. OR, leave it out; if client_name is omitted from the request, then it is system-generated and is the same as client_id.

Also, just to complicate things, this particular AS allows provisioning of multiple dynamic provisioning clients that can implement various policies, such as limiting which restricted scopes might be allowed for clients that they create. I don't think I would need that level of complication just yet;-)

Please let me know how I can help implement this feature.

@n2ygk

This comment has been minimized.

Copy link

commented Apr 8, 2019

PS: It would be really helpful for APIM to (optionally?) automatically add the redirect_uris that it needs for Swagger UI, etc. I've found through experimentation that these are:
GRAVITEE_APIM/swagger-oauth2-redirect.html for swagger "Try it out" (e.g. http://localhost:8002/swagger-oauth2-redirect.html` when running docker local).

@brasseld

This comment has been minimized.

Copy link
Member Author

commented Apr 8, 2019

Hi @n2ygk

This is exactly were we are going.

I've just one concern about the response payload: according to the specification response may contain some additional properties:

  • registration_access_token
  • registration_client_uri

But you didn't have such properties using PingFederate 9.1, or perhaps you remove some parts of the response?

I imagine this is already well understood, but, in case it helps, here is what I would need in order to make this feature work with my OAuth2/OIDC AS (PingFederate 9.1 specifically but I assume any standard OIDC AS would work):

  • AS: Enable Dynamic Client Registration:

    • Configure the AS to require a Bearer Token with a specific scope (e.g. client_creator) for "dynamic provisioning clients" that are permitted to do so.
  • AS: Provision client credentials for the APIM provisioning client with restricted scope (client_creator)

  • APIM: use the client_id and client_secret from above with the Client Credentials flow to get an Access Token with that specific scope (client_creator).

  • APIM: POST to the OIDC registration_endpoint with header "Authorization: Bearer access_token" with a body something like this:

{
  "redirect_uris": [
    "http://localhost:8002",
  ],
  "client_name": "dynamic_client_3",
  "response_types": ["code", "token", "id_token"],
  "token_endpoint_auth_method": "client_secret_basic",
  "scope":"<list of restricted scopes>",
  "grant_types":[
    "authorization_code",
    "implicit"
  ],
  "logo_uri": "https://www.columbia.edu/content/themes/custom/columbia/favicon-crown.png"
}

and get a response like this:

{
    "client_id": "dc-vlq6aFt77gXd6MIpKSgkTH",
    "client_name": "dynamic_client_3",
    "redirect_uris": [
        "http://localhost:8002"
    ],
    "token_endpoint_auth_method": "client_secret_basic",
    "grant_types": [
        "implicit",
        "authorization_code"
    ],
    "client_secret": "7UehninDtpifn1sID4OyMz",
    "client_secret_expires_at": 0,
    "logo_uri": "https://www.columbia.edu/content/themes/custom/columbia/favicon-crown.png",
    "scope": "<list of restricted scopes>",
    "response_types": [
        "code",
        "token",
        "id_token"
    ],
    "validate_using_all_eligible_atms": false,
    "refresh_token_rolling_policy": "server_default",
    "persistent_grant_expiration_type": "server_default",
    "grant_access_session_revocation_api": false
}

Notably, you cannot set the client_id or client_secret: they are automatically generated and associate with the client_name. And, those client names are not unique, so it would be up to APIM to keep track of the names. OR, leave it out; if client_name is omitted from the request, then it is system-generated and is the same as client_id.

Also, just to complicate things, this particular AS allows provisioning of multiple dynamic provisioning clients that can implement various policies, such as limiting which restricted scopes might be allowed for clients that they create. I don't think I would need that level of complication just yet;-)

Please let me know how I can help implement this feature.

@brasseld

This comment has been minimized.

Copy link
Member Author

commented Apr 8, 2019

So, without the registration_access_token and registration_client_uri, it means that the application may not be updatable from APIM.

@n2ygk

This comment has been minimized.

Copy link

commented Apr 8, 2019

@brasseld I guess that's also in RFC 7592. RFC 7591 only specifies dynamic client creation and it appears they haven't caught up with RFC7592 yet. They have a proprietary API that predates OIDC and supports POST and PUT for client registrations. It's what I've been using so far.

I can submit a support ticket and ask if and when they plan to support RFC 7592. Unfortunately the RFC status is Experimental... They tend to follow the Standards Track RFC's.

Perhaps a hook can be provided for proprietary endpoints?

Worst case, each update can POST a new dynamic client and throw the old one away... (ugh.)

I would be OK with switching to an OSS OIDC provider as well, but PF is what we have in production right now.

@lusoalex

This comment has been minimized.

Copy link

commented Apr 9, 2019

OIDC provider as well, but PF is what we ha

Hello n2ygk,

The specification says that client should not construct/form the url and use the registration_client_uri.
But in the meantime they recommend that this endpoint URL should be formed through the use of a server-constructed URL string which combines the Client Registration Endpoint's URL and the issued Client ID for this Client. So you may use the registration_endpoint from oidc discovery.

Gravitee AM offer PATCH (as well as a PUT endpoint in a coming release), which take the same payload than the original POST /register endpoint. Unfortunately you still need to consume these endpoint with the registration_access_token.

PingFederate is in the certified list, they should manage it...
https://openid.net/certification/#OPs

Regards,
Alexandre.

@n2ygk

This comment has been minimized.

Copy link

commented Apr 9, 2019

@lusoalex I'm not super-familiar with OIDC but note that the Client Configuration Endpoint is optional:

The Client Configuration Endpoint is an OAuth 2.0 Protected Resource that MAY be provisioned by the server for a specific Client to be able to view and update its registered information.

In fact the certification table shows that PingFederate is not currently certified as a dynamic OP. Neither is Gravitee AM. Doesn't mean it doesn't do it, just not certified (yet). Looks like gluu is certified across the board as are a few others.

I did submit a feature request to Ping and they added me to the list of customers who've asked for this feature. I'm not holding my breath:-)

Thanks.

brasseld added a commit to gravitee-io/release that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-mongodb that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-redis that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-redis that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-repository-jdbc that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 10, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 11, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 11, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 11, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 11, 2019

brasseld added a commit to gravitee-io/gravitee-repository-mongodb that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-repository that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-repository that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-repository-mongodb that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-management-rest-api that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-management-webui that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-repository-redis that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-repository-test that referenced this issue Apr 16, 2019

tcompiegne added a commit to gravitee-io/gravitee-repository-redis that referenced this issue Apr 16, 2019

brasseld added a commit to gravitee-io/gravitee-repository-jdbc that referenced this issue Apr 16, 2019

aelamrani added a commit to gravitee-io/gravitee-repository-jdbc that referenced this issue Apr 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.