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 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
