search

IdentityServer / IdentityServer3.Admin

Sample Admin UI for IdentityServer3
Apache License 2.0
75 stars 77 forks source link

Dynamic Client Registration #15

Open johncmckim opened 8 years ago

johncmckim commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Hi,

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

dcinzona commented 8 years ago

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 notifications@github.com<mailto:notifications@github.com> 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/IdentityServer/IdentityServer3.Admin/issues/15#issuecomment-180242277.

leastprivilege commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

dcinzona commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

radrad commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 7 years ago

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.