Hi Lalaji, Yes we are already working on this. Thanks.
On Fri, Jun 17, 2016 at 12:38 PM, Lalaji Sureshika <[email protected]> wrote: > Hi Harsha, > > As per your mail,it's going to support the client registration management > spec [1],but you haven't mentioned about support for update/get client > operations and only delete operation..And if we are going to support > this,as per [1],there are some additional response attributes need to be > set in DCR response [eg: a URI pointing to the client configuration > endpoint which will be use for update/delete/get clients]..I think we > should check this as well.. > > [1] https://tools.ietf.org/html/rfc7592 > <https://tools.ietf.org/html/rfc7592> > > Thanks; > > 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? >> >> 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. >> >> 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. >> >> 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 >> >> > > > -- > Lalaji Sureshika > WSO2, Inc.; http://wso2.com/ > email: [email protected]; cell: +94 71 608 6811 > blog: http://lalajisureshika.blogspot.com > > > > _______________________________________________ > 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
