On Tue, Jan 23, 2018 at 1:48 PM, Hasintha Indrajee <[email protected]> wrote:
> > > On Tue, Jan 23, 2018 at 1:18 PM, Darshana Gunawardana <[email protected]> > wrote: > >> Hi Hasintha, >> >> On Tue, Jan 9, 2018 at 5:53 PM, Hasintha Indrajee <[email protected]> >> wrote: >> >>> We have had several discussions with the objective of making these >>> logics more reusable. One of the ideas was to use our carbon-auth-rest >>> valve to authenticate client. Since it has below concerns and gaps we >>> thought of implementing these authenticators as CXF interceptors. >>> >>> 1) Current implementation of rest-auth valves does not have a mechanism >>> to engage authenticators per context. >>> 2) Current implementation of rest-auth valves does not have a way to >>> order the execution sequence of authenticators. >>> 3) Also it seems like using a valve to intercept these specific requests >>> which comes to a context doesn't seem logically correct. Tomcat level >>> doesn't seem to be the correct place to intercept. Instead specific >>> intercepting specific context seems more logical. >>> >> >> Yes, point #3 is a valid point to not to use a tomcat valve, whereas >> other two points are limitations of the existing implementations and I >> could not see them as blockers since if we are anyway have to implement >> those functionalities. >> >> >>> >>> Hence we will be going forward with CXF interceptors for authentication. >>> >> >> Can we consider this interceptor as an another enforcement point like >> tomcat valve and add a new module to identity-carbon-auth-rest component? >> >> The reason is https://github.com/wso2-extens >> ions/identity-carbon-auth-rest component desined to enforce authn & >> authz for rest endponints. And tomcat valve implementation is only an one >> way of intercepting method which not suitable for this context, but we >> still could reuse org.wso2.carbon.identity.auth.service >> and org.wso2.carbon.identity.authz.service modules to manage central >> operations of authenticators. >> >> If this implementation is only applicable for oauth endpoints and if >> there is no usage of any other rest endpoints for similar authentication >> mechanisms, its ok to develop these as separate modules, but we have to >> clearly decide what to use when. >> > > This is a tomcat valve which is getting invoked for all incoming requests > to the server. It's fine to do a user authentication from a tomcat valve > since user authentication is a concept which belongs / relevant to the > whole server. OAuth client authentication is just limited to oauth. Hence > at tomcat level we don't need to implement application specific logics such > as retrieving oauth app info and doing authentication. It's not ideal. > > Further client credentials (including jwts) can come in the body of the > request. At tomcat valve level if we are to consume input stream, it's a > heavy and costly operation. Body consumption is required to decide whether > the request can be handled or not by the client authenticator. Furthermore, > if we consume the input stream at tomcat level we need to wrap the original > request with a backed input stream to make sure rest of the flows are > working fine (At jax-rs level also they read the input stream in order to > build params). These stuff look more workarounds and not ideal to do since > anyway this is costly. > > Furthermore, if we use jax-rs interceptors, we already have consumed body > as params. Hence we don't need to worry about the overhead of building the > body of the request (In certain phases of the jax-rs interceptors we have > consumed body, eg - PRE_INVOKE). > Yes.. As mentioned in my earlier reply, I'm also +1 for adding a new enforcement method. My question is this is something generic enough to add to the identity-carbon-auth-rest or this is oauth specific which does not have any re-usable logic other than the oauth endpoints. > These authenticators are handlers. Hence we can control enabling / > disabling and changing priority through identity.xml configuration. > Can you list sample configuration on this? > The config you quoted will no longer be used. Instead all authenticators > will bind as OSGI services at runtime and can be controlled as our usual > handlers. > +1 Thanks, > > > Since we currently don't have a concept as confidential clients (apps) we > don't do this validation at authenticator levels. Even if authentication > fails client ID will still be there in the context. Application logic > decides whether the grant type is confidential or not. > > In a case of a non confidential clients, if the format of the way we send > out client id is a standard way (as a body param) still the client can get > a token even if authentication fails. If it's a non standard way we need to > plug an authenticator which can extract the client ID from the incoming > request. > > We don't support old authentication handlers. Hence yes, there will be a > code migration. But I don't think it's costly. > > >> Regards, >> >> >> >>> On Tue, Jan 9, 2018 at 10:22 AM, Hasintha Indrajee <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Jan 9, 2018 at 8:29 AM, Isura Karunaratne <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee <[email protected]> >>>>> wrote: >>>>> >>>>>> The idea behind this is to decouple the authentication mechanism used >>>>>> by OAuth2 clients from the rest of the OAuth2 logic, so that different >>>>>> types of client authenticators can be plugged. For an example according >>>>>> to >>>>>> specification [1] client_secret_basic, client_secret_post, >>>>>> client_secret_jwt are few client authentication mechanisms. >>>>>> >>>>>> The client authentication will be done through an extension. Hence >>>>>> different client authentication criteria can be implemented and can be >>>>>> plugged. >>>>>> >>>>>> The interface (API) will consist of three main methods. >>>>>> >>>>>> 1) canAuthenticate - Decides whether the particular authenticator can >>>>>> authenticate the incoming request or not. >>>>>> >>>>>> 2) authenticateClient - Authenticates the client request based on >>>>>> information present. As a result of authentication client ID will be >>>>>> available in the context. >>>>>> >>>>>> 3) getClientId - Depending on the authentication mechanism they way >>>>>> client ID is extracted depends. For an example in JWT client >>>>>> authentication >>>>>> client sends out the client Id within the JWT as the subject. Hence in a >>>>>> case authenticaiton fails, we may need to extract client Id for other >>>>>> puposes. ex - data publishing, if the client is non confidential. >>>>>> >>>>>> The client authenticator has to be implemented as an OSGI bundle and >>>>>> should be deployed in dropins upon building. Also relevant authenticator >>>>>> name has to be configured in identity.xml under client authenticators. >>>>>> >>>>>> <ClientAuthHandlers> >>>>>> >>>>>> <ClientAuthHandler Class="org.wso2.carbon.identit >>>>>> y.oauth2.token.handlers.clientauth.BasicAuthClientAuthHandler"> >>>>>> </ClientAuthHandler> >>>>>> >>>>>> </ClientAuthHandlers> >>>>>> >>>>> >>>>> How are we going to support, non-confidentials clients, will that >>>>> support through another ClientAuthHandler? Also, Do we support >>>>> backword compatibity for exsting ClientAuthHandlers? >>>>> >>>> >>>> Client authenticator will only authenticate if the application is >>>> confidential. If not, still a client authenticator can be introduced to >>>> extract client ID. If no authenticator can handle (either authenticate/ >>>> extract client ID) it will try to extract client ID from the body of the >>>> request and allow to go forward if it's non confidential. Otherwise it will >>>> fail. >>>> >>>> Most probably there will be a code migration required since there will >>>> be subtle changes in client authenticator interface. Ideally as per the >>>> current way there shouldn't be much custom client auth handlers implemented >>>> since the authentication was tightly coupled to the rest of the flow. >>>> >>>>> >>>>> >>>>> Thanks >>>>> Isura >>>>>> >>>>>> >>>>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli >>>>>> entAuthentication >>>>>> <http://www.google.com/url?q=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23ClientAuthentication&sa=D&sntz=1&usg=AFQjCNEcVTdgiIUSObwbxp8OUtTU1By8Rg> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Hasintha Indrajee >>>>>> WSO2, Inc. >>>>>> Mobile:+94 771892453 <077%20189%202453> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Isura Dilhara Karunaratne* >>>>> Associate Technical Lead | WSO2 >>>>> Email: [email protected] >>>>> Mob : +94 772 254 810 <077%20225%204810> >>>>> Blog : http://isurad.blogspot.com/ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hasintha Indrajee >>>> WSO2, Inc. >>>> Mobile:+94 771892453 <077%20189%202453> >>>> >>>> >>> >>> >>> -- >>> Hasintha Indrajee >>> WSO2, Inc. >>> Mobile:+94 771892453 <+94%2077%20189%202453> >>> >>> >> >> >> -- >> Regards, >> >> >> *Darshana Gunawardana*Technical Lead >> WSO2 Inc.; http://wso2.com >> >> *E-mail: [email protected] <[email protected]>* >> *Mobile: +94718566859 <071%20856%206859>*Lean . Enterprise . Middleware >> > > > > -- > Hasintha Indrajee > WSO2, Inc. > Mobile:+94 771892453 <+94%2077%20189%202453> > > -- Regards, *Darshana Gunawardana*Technical Lead WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
