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
