On Tue, Jan 23, 2018 at 2:19 PM, Hasintha Indrajee <hasin...@wso2.com> wrote:
> > > On Tue, Jan 23, 2018 at 2:09 PM, Darshana Gunawardana <darsh...@wso2.com> > wrote: > >> >> >> On Tue, Jan 23, 2018 at 1:48 PM, Hasintha Indrajee <hasin...@wso2.com> >> wrote: >> >>> >>> >>> On Tue, Jan 23, 2018 at 1:18 PM, Darshana Gunawardana <darsh...@wso2.com >>> > wrote: >>> >>>> Hi Hasintha, >>>> >>>> On Tue, Jan 9, 2018 at 5:53 PM, Hasintha Indrajee <hasin...@wso2.com> >>>> 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. >> >> hmm.. This interceptor doesn't have much things which are reusable. The > logic is more jaxrs specific. > Every enforcement implementation is specific to the enforcement method provided by the relevant framework. I'm thinking whether we need to call, org.wso2.carbon.identity.auth.service from the interceptor or is it ok to invoke oauth specific implementation (OAuthClientAuthnService). For example, currently DCR endpoint secured using the org.wso2.carbon.identity.auth.service. If we have CXF interceptor calling org.wso2.carbon.identity.auth.service, do we need to remove using that and move to this method(using OAuthClientAuthnService)? If so why? Thanks, > Hence anyway we need to put this either under lib/runtimes/cxf or should > be bundled with the webapp. We cannot have this interceptor jar in > components/plugins or components/dropins. Because we don't have jax-rs > dependencies at OSGI runtime. Also the existing rest valve is more coupled > with user authentication where as this interceptor is more coupled with > oauth client authentication. > >> >>> These authenticators are handlers. Hence we can control enabling / >>> disabling and changing priority through identity.xml configuration. >>> >> Can you list sample configuration on this? >> > > <EventListener type="org.wso2.carbon.identity > .core.handler.AbstractIdentityMessageHandler" > > name="org.wso2.carbon.identity > .oauth2.OAuthBasicClientAuthenticator" > orderId="11" enable="true"/> > > This uses our existing handler architecture. > >> >> >>> 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 <hasin...@wso2.com> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 9, 2018 at 8:29 AM, Isura Karunaratne <is...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee <hasin...@wso2.com >>>>>>> > 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: is...@wso2.com >>>>>>> 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: darsh...@wso2.com <darsh...@wso2.com>* >>>> *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: darsh...@wso2.com <darsh...@wso2.com>* >> *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: darsh...@wso2.com <darsh...@wso2.com>* *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
