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 <http://wso2.com/>* lean.enterprise.middleware. On Fri, Feb 5, 2016 at 11:07 AM, Sanjeewa Malalgoda <sanje...@wso2.com> 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 <ami...@wso2.com> 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 <thar...@wso2.com> >> 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 >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
