Hi all, I have completed the scope validation implementation. But in this implementation, the entitlement engine has to run for every token validation request even there is no policy defined by the user for a particular service provider. PDP have to go through all existing policies to select the applicable policies. Its an overhead in token validation time.
To avoid this we can introduce "Enable XACML based scope validator" checkbox under Local & Outbound Authentication Configuration. Then users can enable or disable scope validation for that particular service provider. This will be a simple select query and we can use caching. We can check whether the user has enabled the scope validation or not and continue. Any suggestions or improvements are highly appreciated. Thanks and Regards, Senthalan On Fri, Jan 19, 2018 at 6:42 PM, Senthalan Kanagalingam <[email protected]> wrote: > Hi, > > Here is the architecture of the XACML based scope validator. > > > After whether access token has expired, the scope of the token will be > validated using JDBCScopeValidator and XACMLScopeValidator. > The JDBCScopeValidator was already implemented. The XACMLScopeValidator > will create an XACML request from access token and validate using > EntitlementService. > > > Thanks and Regards, > Senthalan > > On Tue, Jan 16, 2018 at 8:59 PM, Dimuthu Leelarathne <[email protected]> > wrote: > >> Hi Johann, >> >> On Tue, Jan 16, 2018 at 8:49 PM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Hi Senthalan, >>> >>> On Tue, Jan 16, 2018 at 12:05 PM, Senthalan Kanagalingam < >>> [email protected]> wrote: >>> >>>> Hi Johann, >>>> >>>> Thanks for the feedback. Currently, I am checking that feature. >>>> >>>> According to my understanding, this feature will be useful to validate >>>> the token scopes against resource scopes. As this validation is done by >>>> JDBCScopeValidator and my implementation will be parallel to it (IS allows >>>> multiple scope validators), do I have to implement validation of the token >>>> scopes against the resource scopes as well? >>>> >>> >>> -1 to have two implementation. There should be only one implementation >>> which is based on XACML. Otherwise it will create overhead in configuring >>> and doesn't work well with tenant model. >>> >> >>> The current scope-role based validation we introduced in IS 5.4.0 will >>> need to be implemented using XACML and be the default policy. The other >>> policies you were planning could be additional template policies we ship >>> with the product. In addition users can have any new policies they want >>> (per tenant). >>> >>> >>>> >>>> Because I have checked with identity-application-authz-xacml[1 >>>> <https://github.com/wso2-extensions/identity-application-authz-xacml>] >>>> and planned to implement validating scopes against the role base and time >>>> base policies only. >>>> >>> >>> Yes, you can use this code and implement a XACML PEP to send a XACML >>> request. But the validation has to happen on the XACML PDP side. >>> >>> What is the difference between the role based policy you are talking and >>> the role based scope validation we implemented in IS 5.4.0? >>> >> >> XACML based scope validation would give fine-grained control and >> flexilibility. I don't have experience with JDBC scope validator but from >> what I know, it is hard to have a generic implementation out of it. >> >> The added avantage is flexibility. You can write your custom XACML >> policies and control how authorization happens. >> >> Let it be XACML or Javascript, we need detailed control to cater for >> different requirements. >> >> thanks, >> Dimuthu >> >> >>> Time based policies can be one of the additional policy templates we >>> ship. >>> >>> Regards, >>> Johann. >>> >>> >>>> >>>> [1] - https://github.com/wso2-extensions/identity-application-au >>>> thz-xacml >>>> >>>> Regards, >>>> Senthalan >>>> >>>> On Mon, Jan 15, 2018 at 8:13 PM, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> *[-IAM, RRT]* >>>>> >>>>> On Mon, Jan 15, 2018 at 8:13 PM, Johann Nallathamby <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Senthalan, >>>>>> >>>>>> Did you check [1]? In this feature *@Isuranga* implement XACML >>>>>> policy to evaluate the permission tree. For this he had to come up with a >>>>>> policy, that defined a custom function. >>>>>> >>>>>> In the above feature if you replace permission with OAuth2 scopes >>>>>> (which is also a representation of permissions in OAuth2 world, and can >>>>>> be >>>>>> assigned to roles from IS 5.4.0 onwards IINM) you will get what you need. >>>>>> Am I right? Do you see any gaps? >>>>>> >>>>>> If my wit is good, this will be the best way to implement this >>>>>> feature. >>>>>> >>>>>> [1] [IAM] Restful API to Evaluate Permission Tree in IS >>>>>> >>>>>> Regards, >>>>>> Johann. >>>>>> >>>>>> On Fri, Jan 12, 2018 at 2:10 PM, Senthalan Kanagalingam < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> As the aim of this project is to validate the scope of the token >>>>>>> against XACML policies. I was wrong about the extension point. There is >>>>>>> no >>>>>>> need to implement it from token validation point. There is an extension >>>>>>> point to extends scope validation("OAuth2ScopeValidator"). And IS >>>>>>> allows multi-scope validators. So I am going start from here. >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> Senthalan >>>>>>> >>>>>>> On Thu, Jan 11, 2018 at 5:35 PM, Senthalan Kanagalingam < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am currently working on implementing XACML based scope validator >>>>>>>> when the resource server tries to validate the OAuth2 token. Users >>>>>>>> can publish their token validation XACML policies to the policy store. >>>>>>>> Here[ >>>>>>>> 1 >>>>>>>> <https://docs.google.com/document/d/1unh9QsDXMXxwbr3SPYLgRG1mKvxphX9VjhRAthHIlQU/edit?usp=sharing>] >>>>>>>> is a sample policy template. >>>>>>>> >>>>>>>> The spec implementation of the OAuth2 token validation is already >>>>>>>> in WSO2 IS. If spec validation passed only this validator will be >>>>>>>> called. >>>>>>>> XACML request will be created using the retrieved information of >>>>>>>> the user. Then that XACML request will be validated using the >>>>>>>> entitlement engine. >>>>>>>> >>>>>>>> There will be a global configuration to enable or disable this >>>>>>>> validation. But in future, it will be implemented as a configurable >>>>>>>> option for each service provider. >>>>>>>> >>>>>>>> WSO2 IS have an extension point to implement TokenValidator[2 >>>>>>>> <https://docs.wso2.com/display/IS540/Extension+Points+for+OAuth#ExtensionPointsforOAuth-OAuth2TokenValidator>]. >>>>>>>> I am planning to implement custom validator >>>>>>>> ("XACMLbasedOAuth2TokenValidator") >>>>>>>> at the point for validation. >>>>>>>> >>>>>>>> I am looking forward to suggestions/comments. >>>>>>>> >>>>>>>> [1] - https://docs.google.com/document/d/1unh9QsDXMXxwbr3SPYLgRG1m >>>>>>>> KvxphX9VjhRAthHIlQU/edit?usp=sharing >>>>>>>> [2] - https://docs.wso2.com/display/IS540/Extension+Points+for+OAu >>>>>>>> th#ExtensionPointsforOAuth-OAuth2TokenValidator >>>>>>>> >>>>>>>> Thanks and Regards, >>>>>>>> Senthalan >>>>>>>> -- >>>>>>>> >>>>>>>> *Senthalan Kanagalingam* >>>>>>>> *Software Engineer - WSO2 Inc.* >>>>>>>> *Mobile : +94 (0) 77 18 77 466* >>>>>>>> <http://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Senthalan Kanagalingam* >>>>>>> *Software Engineer - WSO2 Inc.* >>>>>>> *Mobile : +94 (0) 77 18 77 466* >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johann Dilantha Nallathamby* >>>>>> Senior Lead Solutions Engineer >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile: *+94 77 7776950* >>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>> <https://medium.com/@johann_nallathamby>* >>>>>> Twitter: *@dj_nallaa* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Johann Dilantha Nallathamby* >>>>> Senior Lead Solutions Engineer >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile: *+94 77 7776950* >>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>> Medium: *https://medium.com/@johann_nallathamby >>>>> <https://medium.com/@johann_nallathamby>* >>>>> Twitter: *@dj_nallaa* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Senthalan Kanagalingam* >>>> *Software Engineer - WSO2 Inc.* >>>> *Mobile : +94 (0) 77 18 77 466* >>>> <http://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> >>> *Johann Dilantha Nallathamby* >>> Senior Lead Solutions Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile: *+94 77 7776950* >>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>> <http://www.linkedin.com/in/johann-nallathamby>* >>> Medium: *https://medium.com/@johann_nallathamby >>> <https://medium.com/@johann_nallathamby>* >>> Twitter: *@dj_nallaa* >>> >> >> >> >> -- >> Dimuthu Leelarathne >> Director, Solutions Architecture >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile: +94773661935 <+94%2077%20366%201935> >> Blog: http://muthulee.blogspot.com >> >> Lean . Enterprise . Middleware >> > > > > -- > > *Senthalan Kanagalingam* > *Software Engineer - WSO2 Inc.* > *Mobile : +94 (0) 77 18 77 466* > <http://wso2.com/signature> > -- *Senthalan Kanagalingam* *Software Engineer - WSO2 Inc.* *Mobile : +94 (0) 77 18 77 466* <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
