Hi Geesara, Yes, we already know these gaps, but actually we followed the specifications that was mentioned in the first comment of the mail [1][2]. Why you are not following these public specifications for DCR and DCR Management ? Are there any specific reason for that ?
*Harsha Thirimanna* Associate Tech Lead; WSO2, Inc.; http://wso2.com * <http://www.apache.org/>* *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* *harshathirimannlinked-in: **http: <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* *Lean . Enterprise . Middleware* On Mon, Jun 20, 2016 at 7:33 AM, Geesara Prathap <[email protected]> wrote: > Hi Darshana,Harsha, > > As we need to have common DCR implementation in the platform, if you note > any gap you notice with the current DCR implementation you use, please let > us know. > > Some mismatches are there in the payload is used when creating an OAuth > application using DCR compare to EMM and APIM. You can find out those > implementations in details here[1-2]. Also in EMM, we use the same endpoint > to create and update existing OAuuth application. > > 1. https://docs.wso2.com/display/AM1100/apidocs/store/#guide > 2. > https://docs.wso2.com/display/EMM201/Generating+the+OAuth+2.0+Access+Token > > On Mon, Jun 20, 2016 at 1:17 AM, Harsha Thirimanna <[email protected]> > wrote: > >> Hi Nuwan, >> Please read my comments inline. >> >> On Fri, Jun 17, 2016 at 11:35 AM, Nuwan Dias <[email protected]> wrote: >> >>> Where is the DCR runtime? I presume its in a separate jax-rs hosted on >>> the IS itself? >>> >>> >> The DCR runtime is implemented as a OSGi bundle. I think your question is >> how we are going to expose this as a REST API ? >> We have two ways to do this in IS. >> 1. We have a inbound request framework, which exposes a common servlet >> that accepts any identity requests, build an object model, and delegate the >> processing to a appropriate processor. This was mainly developed to handle >> inbound authentication in IS. >> 2. Standard Swagger/CXF method >> >> For DCR we have used method 1 as an experiment to evaluate what kind of >> development effort it is and any advantages we get using our existing >> inbound framework. >> On the other hand we also developed user information recovery services >> using method 2. >> So we will compare and see between the two approaches what are the pros >> and cons and decide based on that. >> >> However I don't think the differences in implementation will impact the >> clients in anyway, even if we go with method 1 we still can write a swagger >> for the APIs. Then we can generate documentation, client code and any other >> things that support by swagger. >> >> >> >>> Using a valve to handle authentication/authorization won't be ideal IMO. >>> A valve would get hit with every request that the server receives, so it >>> will impact performance. Can't we use a jax-rs filter or a cxf interceptor? >>> If different products need to customise the authentication/authorization >>> part, they can do so by overriding the filter/interceptor configurations. >>> >> >> The approach we are going to take is to expose a service API to pass in >> a object model which will do the authentication and return the result. >> Behind the service API we will provide an SPI to plug-in authenticators >> such as basic auth, oauth2, etc. >> >> The clients of this API can be anything, can be a cxf filter, >> interceptor, servlet filter or valve. It will depend on the use case. We >> can use the relevant configuration files for filters, interceptors, valves, >> etc. to configure the context paths which need authentication. >> >> >>> >>> And I think the default authorization mode should be such that the DCR >>> is only permitted for users with the admin "permission". We could perhaps >>> maintain the permission string in the web.xml so that people can override >>> it if required. >>> >>> >> For authorization we are thinking of providing a generic implementation >> of a cxf filter, interceptor, servlet filter and valve (we might start with >> one or two due to time limitations), which will read the required >> permission string to invoke the particular API using parameters declared in >> the web.xml, server.xml or relevant configuration file. This way users can >> engage/disengage authorization and configure required permissions using the >> configuration files. >> >> Hope this will satisfy all your requirements for a generic implementation >> that can be reused across the board. >> >> >> >>> Thanks, >>> NuwanD. >>> >>> On Fri, Jun 17, 2016 at 2:20 AM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thu, Jun 16, 2016 at 10:18 PM, Farasath Ahamed <[email protected]> >>>> wrote: >>>> >>>>> Hi Harsha, >>>>> >>>>> When implementing User Managed Access 1.0 for WSO2 Identity Server, we >>>>> implemented a valve similar to what you have proposed here. You can find >>>>> the implemented tomcat valve here[1]. Since the endpoints implemented for >>>>> UMA were OAuth protected, the idea was to do the OAuth token validation at >>>>> the valve and pass the result to each endpoint by setting the token >>>>> validation response as an attribute in the request forwarded to the >>>>> endpoint. >>>>> >>>>> >>>>> [1] >>>>> https://github.com/mefarazath/carbon-identity/blob/gsoc-uma/components/tomcat-valve/src/main/java/org/wso2/carbon/identity/tomcat/valve/OAuthAccessTokenValidatorValve.java >>>>> >>>> >>>> +1. >>>> >>>> I think it was the same code that was reused by EMM team in their DCR >>>> implementation to do authentication, which is now ported by Harsha to IS, >>>> except Harsha didn't port the authentication piece yet, because we decided >>>> it needs to be externalized from the DCR implementation. >>>> >>>> Check mail thread [2] also for related discussion. >>>> [2] Decoupling client_id/client_secret based OAuth 2.0 client >>>> authentication from the token endpoint >>>> >>>> >>>>> >>>>> Thanks, >>>>> Farasath Ahamed >>>>> Software Engineer, >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> >>>>> Email: [email protected] >>>>> Mobile: +94777603866 >>>>> Blog: blog.farazath.com >>>>> Twitter: @farazath619 <https://twitter.com/farazath619> >>>>> >>>>> On Fri, Jun 17, 2016 at 1:12 AM, Harsha Thirimanna <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> We have covered three [1], [2], [3] specification(not fully, but >>>>>> mostly used areas) with this feature. >>>>>> >>>>>> OAuth application registration and delete >>>>>> OIDC application registration. >>>>>> >>>>>> *Client Registration Request* >>>>>> >>>>>> To register a new Client at the Authorization Server, the Client >>>>>> sends an HTTP POST message to the Client Registration Endpoint with any >>>>>> Client Metadata parameters that the Client chooses to specify for itself >>>>>> during the registration. The Authorization Server assigns this Client a >>>>>> unique Client Identifier, optionally assigns a Client Secret, and >>>>>> associates the Metadata given in the request with the issued Client >>>>>> Identifier. >>>>>> >>>>>> *Sample Request* >>>>>> >>>>>> POST /identity/connect/register HTTP/1.1 >>>>>> Content-Type: application/json >>>>>> Accept: application/json >>>>>> Host: server.example.com >>>>>> >>>>>> { >>>>>> "redirect_uris": ["server.example.com"], >>>>>> "client_name": "rest_api_store_1", >>>>>> "ext_param_owner": "admin", >>>>>> "grant_types": ["password"] >>>>>> } >>>>>> >>>>>> >>>>>> *Response* >>>>>> >>>>>> HTTP/1.1 201 Created >>>>>> Content-Type: application/json >>>>>> Cache-Control: no-store >>>>>> Pragma: no-cache >>>>>> >>>>>> { >>>>>> "client_id": "s6BhdRkqt3", >>>>>> "client_secret": >>>>>> "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk", >>>>>> "client_secret_expires_at": 1577858400, >>>>>> "redirect_uris": >>>>>> ["server.example.com"], >>>>>> "client_name": "admin_rest_api_store_1" >>>>>> } >>>>>> >>>>>> >>>>>> *Error Response* >>>>>> >>>>>> HTTP/1.1 400 Bad Request >>>>>> Content-Type: application/json >>>>>> Cache-Control: no-store >>>>>> Pragma: no-cache >>>>>> >>>>>> { >>>>>> "error": "invalid_redirect_uri", >>>>>> "error_description": "One or more redirect_uri values are invalid" >>>>>> } >>>>>> >>>>>> >>>>>> *Client UnRegistration Request* >>>>>> >>>>>> To deprovision itself on the authorization server, the client makes >>>>>> an HTTP DELETE request to the client configuration endpoint. >>>>>> DELETE /identity/register/s6BhdRkqt3 HTTP/1.1 >>>>>> Host: server.example.com >>>>>> >>>>>> Adding ‘client_id’ value as a url path variable. >>>>>> >>>>>> >>>>>> To implement this, we used our new framework implementation and >>>>>> oidc.dcr feature was extended by the oath.dcr feature. >>>>>> >>>>>> Now we have to implement an authentication layer for this and we are >>>>>> trying to implement it as a valve to make it common to our all the rest >>>>>> api's. But we have another concern, if we implemented like that, would it >>>>>> be a performance impact because all the request will go through that even >>>>>> though those are not belong to this context or not. If it is, then we can >>>>>> write it in generic way and front to the each rest api separately. >>>>>> >>>>>> In this case we have to think about the authorization model as well. >>>>>> >>>>>> >>>>>> [1] https://tools.ietf.org/html/rfc7591 >>>>>> [2] https://tools.ietf.org/html/rfc7592 >>>>>> [3] https://openid.net/specs/openid-connect-registration-1_0.html >>>>>> >>>>>> thanks >>>>>> >>>>>> *Harsha Thirimanna* >>>>>> Associate Tech Lead; WSO2, Inc.; http://wso2.com >>>>>> * <http://www.apache.org/>* >>>>>> *email: **[email protected]* <[email protected]>* cell: +94 71 5186770 * >>>>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>* >>>>>> *harshathirimannlinked-in: **http: >>>>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 >>>>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>* >>>>>> >>>>>> *Lean . Enterprise . Middleware* >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Technical Lead & Product Lead of WSO2 Identity Server >>>> Governance Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Technical Lead - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Geesara Prathap Kulathunga > Software Engineer > WSO2 Inc; http://wso2.com > Mobile : +940772684174 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
