On Tue, Jan 23, 2018 at 2:09 PM, Darshana Gunawardana <[email protected]> wrote:
> > > 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. > > hmm.. This interceptor doesn't have much things which are reusable. The logic is more jaxrs specific. 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 <[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 <071%20856%206859>*Lean . Enterprise . Middleware > -- Hasintha Indrajee WSO2, Inc. Mobile:+94 771892453
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
