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
