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
