Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

[Harshan Liyanage]

Hi,

Please find my comments inline.

@Roshan, Yes that is the proper way of getting resource data according to
Richardson maturity model for REST APIs.We provide resource ID and do get
to fetch resource.
I think we may add it for users to get data later.
They can change grant types, scopes or app name by logging to management
console. May be later we can support edit application with this web
application.
But as of now we focused on create and delete part only. But definitely we
need to look at edit option as well.
In that case we need to check user name and verify if app owner is edit app
or not. Otherwise anyone can edit other peoples apps.

We have done the same for EMM as well. However when a client invokes DCR
endpoint (POST) for creating a oauth-client, we send the data of the
oauth-client app if one already exists for the same client. I think we can
do the same here.
+1 for adding update API as well. But I think update API will be less
likely to be used as there may be very less use-cases where we need to
update the existing oauth-clients. So I believe you can add it later (In
such extreme cases clients can be updated using Carbon console as Sanjeewa
mentioned).

Registration endpoint may named as oauth2/dcr or oauth2/register.
If you use something like "oauth2/dcr" or "oauth2/register", you will run
into problems for GET and PUT endpoints as the both resource definitions
(dcr and register) does not make any sense when it comes to REST. I suggest
you could use something like "oauth2/client" which is more informative and
has a good resource definition.

Thanks,

Harshan Liyanage
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.

On Fri, Feb 5, 2016 at 11:07 AM, Sanjeewa Malalgoda 
wrote:

> As we discussed this endpoint will be secured with Basic Auth.
> That means anyone who has login permission can create OAuth application in
> system.
> If need we may add special permission to create OAuth applications.
>
> There is a profile called open registration for OAuth applications but its
> vulnerable to DoS attacks.
> So we must use some form of authentication.
> And spec says previously generated token also can use for this. But IMO it
> will not suitable for our requirement.
>
> @Roshan, Yes that is the proper way of getting resource data according to
> Richardson maturity model for REST APIs.We provide resource ID and do get
> to fetch resource.
> I think we may add it for users to get data later.
> They can change grant types, scopes or app name by logging to management
> console. May be later we can support edit application with this web
> application.
> But as of now we focused on create and delete part only. But definitely we
> need to look at edit option as well.
> In that case we need to check user name and verify if app owner is edit
> app or not. Otherwise anyone can edit other peoples apps.
>
> Registration endpoint may named as oauth2/dcr or oauth2/register.
> @Amila, having register is mandatory for registration URL?
> If we let users to edit/delete as well then having resource name as
> "register" may be bit of confusing.
>
> And most important thing this registration endpoint should secured with
> TLS 1.2 as per spec section 5[
> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30#section-5].
>
> Thanks,
> sanjeewa.
>
>
>
> On Fri, Feb 5, 2016 at 12:34 AM, Amila De Silva  wrote:
>
>> Hi Tharika,
>>
>> Since *"**saasApp"* is not a common parameter as per the spec, you might
>> have to emphasise the usage of it.
>>
>> Just noticed that in the excerpt you've provided request is sent to a
>> resource named oauthdcr. Better if we can name it as /regsiter to show
>> the conformity with the spec.
>>
>> On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are planning of $subject.
>>>
>>> In some use cases, it is desirable or necessary to allow OAuth clients
>>> to obtain authorization from an authorization server without the two
>>> parties having previously interacted. Therefore in order for the
>>> authorization server to accurately represent to end users which client is
>>> seeking authorization to access the end user’s resources, a method for
>>> automatic and unique registration of clients is needed. This is where the
>>> Dynamic Client Registration protocol comes into play.
>>>
>>> The RFC related to this feature can be found in [1]
>>>
>>> *Problem*
>>>
>>> Currently, we have implementations for DCR in products like WSO2 API
>>> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
>>> of the functionality. Since this feature should ideally reside in the WSO2
>>> Identity Server, we are trying to move it to their code base so that it
>>> will be available to the entire WSO2 platform.
>>>
>>> *Solution*
>>>
>>> We are trying to implement it so 

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

[Nuwan Dias]

Hi Tharika,

Have you decided on the security of this endpoint?

Thanks,
NuwanD.

On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma 
wrote:

> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an authorization server without the two parties
> having previously interacted. Therefore in order for the authorization
> server to accurately represent to end users which client is seeking
> authorization to access the end user’s resources, a method for automatic
> and unique registration of clients is needed. This is where the Dynamic
> Client Registration protocol comes into play.
>
> The RFC related to this feature can be found in [1]
>
> *Problem*
>
> Currently, we have implementations for DCR in products like WSO2 API
> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
> of the functionality. Since this feature should ideally reside in the WSO2
> Identity Server, we are trying to move it to their code base so that it
> will be available to the entire WSO2 platform.
>
> *Solution*
>
> We are trying to implement it so that the endpoint for registering and
> unregistering an OAuth client will be available through the oauth2 web app
> being deployed through the Identity Server.
>
>
> This feature is implemented as an OSGi service. The endpoint details will
> be as follows.
>
>
> Registering an OAuth 2.0 client application will take place through a POST
> request to the registration endpoint. For example see the following sample
> request,
>
>
> POST *oauth2/oauthdcr* HTTP/1.1
> Content-Type: application/json
>
> {
> "callbackUrl": "www.google.lk",
> "clientName": "MyApp",   //OAuth application name
> "tokenScope": "Production",
> "owner": "admin",   //User name of application owner
> "grantType": "password refresh_token",   //space separated grant-type
> list
> "saasApp" :true  //indicates whether this is a SaaS app or not
> }
>
>
> Upon successful registration you'll receive a json payload including the
> client-name, client-id, client-secret and the callback-url.
>
>
> Similarly unregistering an OAuth 2.0 client application will take place
> through a DELETE request to the registration endpoint with the
> applicationName, userId(username of the application owner) and the
> consumerKey taken in as query parameters in the request.
>
> [1] https://tools.ietf.org/html/rfc7591
>
>
> Tharika Madurapperuma
> Intern - Software Engineering
> WSO2, Inc.
> Mobile : +94777-875-624
>



-- 
Nuwan Dias

Technical Lead - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

[Roshan Wijesena]

Hi Tharika,

+1. Have you thought about a way to fetch/update a DCR application?

There is a way you can achieve this by providing  an access_token and
registration URL upon DCR registration. So then users can persist that
access_token and URL and can be used in future in order to edit the DCR
application. This approach has currently used by MITRED identity server's
DCR endpoint. [1].

For example: When you register a DCR application, the response payload  may
be  something  like below,

{ "client_id": "4547fc03-a6f3-4641-8e1f-84eb13093e5c", "client_secret":
"ANcxv7xx00H9yO-8dg2-avCKBcqdeK3E-1d-yboYYX3J-rAoGLDaXLPJzR6u7mZAEnhgavbxE0fAm6vfeDy9QiM",
"client_secret_expires_at": 0, "client_id_issued_at": 1407892001, *
"registration_access_token":
"eyJhbGciOiJSUzI1NiJ9.eyJhdWQiOlsiNDU0N2ZjMDMtYTZmMy00NjQxLThlMWYtODRlYjEzMDkzZTVjIl0sImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo4MDgwXC9vcGVuaWQtY29ubmVjdC1zZXJ2ZXItd2ViYXBwXC8iLCJqdGkiOiI3MWI2MDlhYi00NmExLTQxMzItOTdkZC05Y2RmYTY0NDEyY2QiLCJpYXQiOjE0MDc4OTIwMDF9.SvJEMThaCmBj5qdl-NibA9UyAKf2uvOqdewYeOh7nHcziiZVIVOrhozfQEgK31OWmmdWxmw3cB2wMqhadqP4mPJGr7gpLIq0N4WF-2zVpPDJZhT7BZESpiKGwXEYiGHYE1xPsd8nKaGuXFKW9U3U31kTG9Ud5BeKxaAgs1lZAGM",
"registration_client_uri":
"http:\/\/localhost:8080\/IDP\/register\/4547fc03-a6f3-4641-8e1f-84eb13093e5c",*
"redirect_uris": [ "google.com" ], "client_name": "Simple Web App",
"contacts": [ ], "token_endpoint_auth_method": "client_secret_basic",
"scope": "phone openid offline_access address email profile",
"grant_types": [ "authorization_code", "refresh_token" ], "response_types":
[ "code" ], "application_type": "web", "default_acr_values": [ ],
"request_uris": [ ] }

To fetch a DCR application data you can use a GET request something like
below. What is your plan?

http://localhost:8080/openid-connect-server-webapp/dcrenpoint/

Authorization:Bearer 

Further, Are we going to have an introspection endpoint for this
implementation?

For the security, The spec [2] says to use an initial access_token to
protect the endpoint. This need to be discussed more.

[1] https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server.
[2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-30#page-33




On Thu, Feb 4, 2016 at 10:22 AM, Tharika Madurapperuma 
wrote:

> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an authorization server without the two parties
> having previously interacted. Therefore in order for the authorization
> server to accurately represent to end users which client is seeking
> authorization to access the end user’s resources, a method for automatic
> and unique registration of clients is needed. This is where the Dynamic
> Client Registration protocol comes into play.
>
> The RFC related to this feature can be found in [1]
>
> *Problem*
>
> Currently, we have implementations for DCR in products like WSO2 API
> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
> of the functionality. Since this feature should ideally reside in the WSO2
> Identity Server, we are trying to move it to their code base so that it
> will be available to the entire WSO2 platform.
>
> *Solution*
>
> We are trying to implement it so that the endpoint for registering and
> unregistering an OAuth client will be available through the oauth2 web app
> being deployed through the Identity Server.
>
>
> This feature is implemented as an OSGi service. The endpoint details will
> be as follows.
>
>
> Registering an OAuth 2.0 client application will take place through a POST
> request to the registration endpoint. For example see the following sample
> request,
>
>
> POST *oauth2/oauthdcr* HTTP/1.1
> Content-Type: application/json
>
> {
> "callbackUrl": "www.google.lk",
> "clientName": "MyApp",   //OAuth application name
> "tokenScope": "Production",
> "owner": "admin",   //User name of application owner
> "grantType": "password refresh_token",   //space separated grant-type
> list
> "saasApp" :true  //indicates whether this is a SaaS app or not
> }
>
>
> Upon successful registration you'll receive a json payload including the
> client-name, client-id, client-secret and the callback-url.
>
>
> Similarly unregistering an OAuth 2.0 client application will take place
> through a DELETE request to the registration endpoint with the
> applicationName, userId(username of the application owner) and the
> consumerKey taken in as query parameters in the request.
>
> [1] https://tools.ietf.org/html/rfc7591
>
>
> Tharika Madurapperuma
> Intern - Software Engineering
> WSO2, Inc.
> Mobile : +94777-875-624
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Roshan Wijesena.
Senior Software Engineer-WSO2 Inc.
Mobile: *+94719154640*
Email: ros...@wso2.com
*WSO2, Inc. :** wso2.com *

Re: [Architecture] Moving the OAuth 2.0 Dynamic Client Registration(DCR) feature to WSO2 Identity Server

[Amila De Silva]

Hi Tharika,

Since *"**saasApp"* is not a common parameter as per the spec, you might
have to emphasise the usage of it.

Just noticed that in the excerpt you've provided request is sent to a
resource named oauthdcr. Better if we can name it as /regsiter to show the
conformity with the spec.

On Thu, Feb 4, 2016 at 9:52 PM, Tharika Madurapperuma 
wrote:

> Hi All,
>
> We are planning of $subject.
>
> In some use cases, it is desirable or necessary to allow OAuth clients to
> obtain authorization from an authorization server without the two parties
> having previously interacted. Therefore in order for the authorization
> server to accurately represent to end users which client is seeking
> authorization to access the end user’s resources, a method for automatic
> and unique registration of clients is needed. This is where the Dynamic
> Client Registration protocol comes into play.
>
> The RFC related to this feature can be found in [1]
>
> *Problem*
>
> Currently, we have implementations for DCR in products like WSO2 API
> Manager and WSO2 Enterprise Mobility Manager. This leads to a duplication
> of the functionality. Since this feature should ideally reside in the WSO2
> Identity Server, we are trying to move it to their code base so that it
> will be available to the entire WSO2 platform.
>
> *Solution*
>
> We are trying to implement it so that the endpoint for registering and
> unregistering an OAuth client will be available through the oauth2 web app
> being deployed through the Identity Server.
>
>
> This feature is implemented as an OSGi service. The endpoint details will
> be as follows.
>
>
> Registering an OAuth 2.0 client application will take place through a POST
> request to the registration endpoint. For example see the following sample
> request,
>
>
> POST *oauth2/oauthdcr* HTTP/1.1
> Content-Type: application/json
>
> {
> "callbackUrl": "www.google.lk",
> "clientName": "MyApp",   //OAuth application name
> "tokenScope": "Production",
> "owner": "admin",   //User name of application owner
> "grantType": "password refresh_token",   //space separated grant-type
> list
> "saasApp" :true  //indicates whether this is a SaaS app or not
> }
>
>
> Upon successful registration you'll receive a json payload including the
> client-name, client-id, client-secret and the callback-url.
>
>
> Similarly unregistering an OAuth 2.0 client application will take place
> through a DELETE request to the registration endpoint with the
> applicationName, userId(username of the application owner) and the
> consumerKey taken in as query parameters in the request.
>
> [1] https://tools.ietf.org/html/rfc7591
>
>
> Tharika Madurapperuma
> Intern - Software Engineering
> WSO2, Inc.
> Mobile : +94777-875-624
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture