Dynamic Client Registration

[johncmckim]

In #308 and #2288, the admin project was mentioned as the most appropriate place to implement OpenID Connect Dynamic Client Registration and OAuth 2.0 Dynamic Client Registration Protocol.

I think Dynamic Client Registration is really important for scaling an OpenID / OAuth 2.0 solution. Managing clients becomes a difficult task when either one entity needs access to tens of APIs via individual clients or you want to give tens or hundreds of clients access to your API.

Do you think OpenID DCR and OAuth 2.0 DCRP fit into this project? I am personally really interested in a solution for Dynamic Client Registration. As a result, I am happy to contribute you're happy to accept contributions for this.

[brockallen]

I think this would still be a separate project (yet probably rely upon the DB update plumbing from this admin project). Something to discuss. // @leastprivilege

[dcinzona]

Agree with @brockallen - should be an extension to IdSrv to support this functionality. I would also be interested in seeing this implemented somehow. We don't want to have it as part of the admin, because we don't want the admin exposed to the public.

[leastprivilege]

Well - it could be a stand alone web api (or pure MW) that you can add to any host (including the idsrv host). It would also need a client.

[johncmckim]

This poor issue can't seem to find a home. Whilst I have zero interest in implementing Dynamic Client Registration alone, I've put together a little experiment https://github.com/johncmckim/DCRP. All this does is take a Registration Request and store it using the IdentityServer3.EntityFramework package. The validation is pretty much non-existent and there are a lot of fields I don't know how to handle.

I think this experiment shows that this issue really belongs in it's own project. This project would just handle the API and registration request validation. It would then rely on storage services that save the client into a store that is used by the identity server (or in theory other).

I'm happy enough to see this issue closed since it doesn't belong here. However, It would be nice to know if this Dynamic Client Registration is something that can come under the IdentityServer organisation and if there is interest in developing it.

Lastly, I've mentioned this before, I've got a big interest in this so I'm happy to contribute. There's just no way I would take it on alone.

[leastprivilege]

Hi,

could you tell me exactly what your use case is - and how you intend to use the DCR endpoint?

[dcinzona]

I was thinking more along the lines of a self service portal where one could enable client management to the general public much like Twitter, Google, Facebook, etc. maybe a trimmed down version of admin, where users could register new clients and only manage their own clients.

On Feb 5, 2016, at 2:56 AM, Dominick Baier <[email protected]mailto:[email protected]> wrote:

Hi,

could you tell me exactly what your use case is - and how you intend to use the DCR endpoint?

Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-180242277.

[leastprivilege]

But that's something completely different...

why do you need the protocol - is my real question.

You are saying you want a portal - why wouldn't that portal talk to the database directly? How do you want to handle authentication? and moderation?

I am not against implementing DCR. But everytime I ask these questions it turns out that DCR is not the problem - unless you want to support DCR clients that should be able to programmatically register clients on your server using a standard protocol.

thoughts?

[dcinzona]

The ultimate goal for us would be to allow users who want to integrate with our IdP a method of self-service. This would reduce the development load as long as there's a mechanism available for our users to be able to do this.

Here's the example:
We have a partner that wants to build an app that supports authentication via our IdP. We can add a client for their app, but that requires quite a bit of back and forth. And then the process is repeated for each partner that wants to create an app, or for each app that is being created. Ideally, we would like to have a portal where the partner can authenticate with our systems, see which clients they have and manage those or create new ones.

The requirements would be:

1. Support self service registration of new clients by users (partners or developers) (permissions are set via roles)
2. Allow specification of scopes available at the service configuration level: i.e. DCR allowed Scopes = "scope1","scope2", etc.
3. Admins should be able to revoke or disable any clients created in this way.
4. Users (partners or developers) unless admin, can only see their specific clients.

Does that make sense?

[leastprivilege]

Sure that makes total sense. But where exactly in this process would you need the DCR protocol?

[dcinzona]

It could be a separate process, not injected into any current flow, but instead it's own endpoint (much like .well-known for discovery. The DCR could be it's own endpoint where the protocol takes effect, generating a new client.
Perhaps as a factory service that would piggyback off of entity framework or in-memory.
factory.Register<DynamicClientRegistration>(options) or factory.UseInMemoryClientRegistration(options)

With the above, we would not need the portal. Developers would register their clients using this protocol and, thus, not require any additional UI.

[johncmckim]

In our use case, we sell a software product to clients. This software integrates with the client's LDAP, CAS or SAML service to provide authentication. IdentityServer is then used to allow third parties to integrate with the APIs and Authenticate users.

Between dev, test and prod, there would be 200+ installations of this software. Each client might have individual integrations that use the APIs and we have partners that can integrate with anyone.

The problem is giving those partners to have access to all those different installations. Right now it's very manual which wastes a lot of time and is not very secure. Our options seem to be:

• Manually adding each each cient via admin - manual and not very secure (access keys emailed to people)
• Add a developer portal to the software - takes away support for us, but your partners still need to register at each installation of the software. Managing tens or hundreds of accounts would be a big pain for our partners
• Some kind of custom web service - I would be wary of this as a security flaw would be terrible
• Dynamic Client Registration - no more manual setup and secure transfer of keys

Authentication and moderation are issues. I see Software Statements from the OAuth 2.0 protocol helping with this. I imagine a system where a Software Statement for a 'Portal' is embedded in the code, allowing the portal to access the registration endpoint. Partners can then register with the portal and get access tokens that can be used on the Registration Endpoint for each website. Unauthenticated requests would not be allowed. Moderation can be done in the portal to restrict the people that integrate with us.

If there's a simpler way to do this, I'd love to hear it. But so far I cannot think of a better way to do this.

[brockallen]

Dynamic Client Registration - no more manual setup and secure transfer of keys

this big problem with this in general (not your approach, so i'm not criticizing) is how do you allow in the dynamic registrations you want to allow, and prevent the ones you don't.

[johncmckim]

I do understand that this is an issue. Hence why I would have a 'Portal' to control this. I wouldn't allow Unauthenticated requests to the Registration Endpoint. The spec says you SHOULD allow unauthenticated requests, not MUST. The 'Portal' (a separate web app) would then control who can and cannot get access tokens for the registration endpoint.

I think the OAuth spec tries to solve this problem with Software Statements. While they're good for apps you know about beforehand, I think a combination of Software Statements and an authenticated Registration Endpoint solves that problem in the best way.

[alhardy]

I also starting to investigate this. We implemented our own admin api and ui for managing clients, we're now looking at a self service portal, which is when I found the DCR spec.

The portal could implement the DCR spec but I see many other custom bits and pieces that a portal would need so I don't really see the benefit of the using the spec for this?

[leastprivilege]

I agree - DCR makes sense if you want to provide a standard way for third parties to do automated self-service.

[radrad]

This video shows the screen for client registration with an openid connect provider:
https://www.gluu.org/how-to-dynamically-register-openid-connect-client/
It would be great if https://github.com/IdentityServer/IdentityServer3.Admin would implement this funcionality.

[xiongtec]

What was the end result of this discussion? @johncmckim did you went ahead and implemented that feature? I to am in need of this feature and am going to implement this, wondering if you done anything.

[johncmckim]

@xiongtec there is no outcome on this issue so far. At this stage, I think the only way this will be implemented is via a community add-on.

I created a little experiment a while ago to look at how it might be implemented https://github.com/johncmckim/DCRP. However, it is nowhere near production ready. I'm not even sure if I want that project to become production ready. I would like to see a group of people better versed in the spec involved in a project to implement DCRP.

[alhardy]

Ive started building this in aspnet core following IdentityServer4 design, although the spec leaves a fair bit open.

Ill make the repo public shortly when its a bit more complete

[gerektoolhy]

Just to chip in, we are looking into this area as well.

You are saying you want a portal - why wouldn't that portal talk to the database directly?

Our portal is a different service from IdentityServer instance. Portal will then talk to IdentityServer instance via API to create/update dynamically clients. We could create our own API, or we could implement (maybe partially?) DCR as a contrib package.