On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray <[email protected]> wrote:
> To overcome the above limitation where we cannot plug custom > authentication, i came up with the below approach. > > Having one interceptor and delegate authentication to an interface. > Implementation of the interface is configurable so that we can plug custom > authentication as well. > > [image: Inline image 1] > > One limitation here is we can have only one auth type active at a time. > > Hi Sanjeewa, > > Shall we continue with this approach until we get a proper fix from msf4j? > It's ok to use above approach as a temporary workaround till we get proper solution from MSF4J, but please make sure to implement only required features in a simple manner because you have to discard this and have to use proper MSF4J approach before any release. By looking at issues faced by API-M and IS teams we have few issues to solve, 1. Ability to apply/skip Interceptors in global and per-service levels 2. Ability to define the order of Interceptors 3. Ability to intercept response messages The good news is JAX-RS 2.0 spec is already solved these issues and we can adopt their concepts easily to MSF4J programming model. Please refer solution for each issue below. *1. Ability to intercept response messages * JAX-RS defines 2 interfaces as ContainerRequestFilter[1] and ContainerResponseFilter[2] to intercept request and response messages, IMO these 2 interfaces are much clean and standard then current MSF4J Interceptor[3] concept where response intercepting is not simple. *2. Ability to apply/skip Interceptors in global and per-service levels * Annotation driven NameBinding[4] concept defined for JAX-RS Filters is very flexible and easy to use as well. This NameBinding[4] feature enables to apply JAX-RS Filters at global, per-Resource or even per-sub-Resource level. *3. Define the order of Interceptors * JAX-RS defines several message processing extension points such as Pre, PreMatch, Post, it's possible to apply Filters during some of these message processing stages, as an example refer PreMatching[5] annotation. Further, to define fine grained order of Filters JAX-RS reuse Java's standard Priority[1] annotation, through this annotation numeric priority value can be define per Filters basis. JAX-RS already provide set of pre-defined Priories here[6] I have setup a meeting in next Wednesday, if we can cater current requirements using above concepts let's go ahead with JAX-RS Filters. [1] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/container/ContainerRequestFilter.html [2] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/ContainerResponseFilter.html [3] - https://github.com/wso2/msf4j/blob/master/core/src/main/java/org/wso2/msf4j/Interceptor.java [4] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/NameBinding.html [5] - https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/index.html?javax/ws/rs/container/PreMatching.html [6] - https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/Priorities.html Thanks ! > > > > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 <+94%2077%20262%209512> > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray <[email protected]> wrote: > >> Hi Thilina, >>> >>> And also if there are multiple interceptors and one interceptor returns >>> false from its' preCaall then the invocation chain will not continue >>> further. >>> >>> So Is this implies if preCall returns 'true' then the invocation chain >>> will continue further? >>> >> >> Yes >> >> I was thinking to return 'true' if particular auth header type(Basic, >> Bearer) is not found in an interceptor, so that it will check the other >> available interceptors. >> But i guess this approach may also fail if the request header type is not >> provided may be by mistake. >> Because all the interceptors will return true and will it be taken as a >> valid authorization? >> >> >> Thanks & Regards, >> Ishara Cooray >> Senior Software Engineer >> Mobile : +9477 262 9512 <+94%2077%20262%209512> >> WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez <[email protected]> wrote: >> >>> >>> >>> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray <[email protected]> wrote: >>> >>>> Hi Thilina, >>>> >>>> And also if there are multiple interceptors and one interceptor returns >>>> false from its' preCaall then the invocation chain will not continue >>>> further. >>>> >>>> So Is this implies if preCall returns 'true' then the invocation chain >>>> will continue further? >>>> >>> >>> Yes >>> >>> >>>> If that is the case we can return true in our overridden preCall method >>>> so that it goes to next Interceptor. >>>> >>>> >>>> Thanks & Regards, >>>> Ishara Cooray >>>> Senior Software Engineer >>>> Mobile : +9477 262 9512 <077%20262%209512> >>>> WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> How about supporting JAXRS filters? >>>>> >>>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Ishara, >>>>>> >>>>>> As you have mentioned, with the current architecture we can't set the >>>>>> specific interceptor for a particular service but rather to all services >>>>>> in >>>>>> the registry. And also if there are multiple interceptors and one >>>>>> interceptor returns false from its' preCaall then the invocation chain >>>>>> will >>>>>> not continue further. >>>>>> >>>>>> IMHO we have few options >>>>>> >>>>>> - We can implement a way to register specific interceptors to >>>>>> specific services >>>>>> - We can support JAX-RS Filters >>>>>> - We can provide a way to skip some interceptors for specific >>>>>> services >>>>>> >>>>>> @Azeez WDYT? >>>>>> >>>>>> Thanks >>>>>> Thusitha >>>>>> >>>>>> >>>>>> On Wed, Dec 7, 2016 at 10:56 AM, Ishara Cooray <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> HI, >>>>>>> >>>>>>> We are using MSF4J interceptor for securing REST APIs in API >>>>>>> Manager. [1] As for now Interceptor registration happens at the class >>>>>>> level >>>>>>> @Component annotation as below. >>>>>>> >>>>>>> @Component( >>>>>>> name = "org.wso2.carbon.apimgt.rest.a >>>>>>> pi.common.interceptors.OAUTH2SecurityInterceptor", >>>>>>> service = Interceptor.class, >>>>>>> immediate = true >>>>>>> ) >>>>>>> The limitations here are >>>>>>> >>>>>>> 1. it is not possible to have more than one interceptor that >>>>>>> will dynamically pick when an api call is received(Because the order >>>>>>> matters and we are not certain which interceptor will take into >>>>>>> effect ). >>>>>>> 2. We cannot explicitly configure to use Custom interceptors >>>>>>> because of the above[1] reason. >>>>>>> >>>>>>> Do we have any plans for these limitations? >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Ishara Cooray >>>>>>> Senior Software Engineer >>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thusitha Dayaratne >>>>>> Software Engineer >>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>> >>>>>> Mobile +94712756809 <071%20275%206809> >>>>>> Blog alokayasoya.blogspot.com >>>>>> About http://about.me/thusithathilina >>>>>> <http://wso2.com/signature> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Afkham Azeez* >>>>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com >>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>> * <http://www.apache.org/>* >>>>> *email: **[email protected]* <[email protected]> >>>>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * >>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>> *twitter: **http://twitter.com/afkham_azeez* >>>>> <http://twitter.com/afkham_azeez> >>>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>> >>>>> *Lean . Enterprise . Middleware* >>>>> >>>> >>>> >>> >>> >>> -- >>> *Afkham Azeez* >>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com >>> Member; Apache Software Foundation; http://www.apache.org/ >>> * <http://www.apache.org/>* >>> *email: **[email protected]* <[email protected]> >>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: * >>> *http://blog.afkham.org* <http://blog.afkham.org> >>> *twitter: **http://twitter.com/afkham_azeez* >>> <http://twitter.com/afkham_azeez> >>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>> <http://lk.linkedin.com/in/afkhamazeez>* >>> >>> *Lean . Enterprise . Middleware* >>> >> >> > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Sagara Gunathunga Associate Director / Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
