Re: [Architecture] Moving XACML to C5

[Harsha Thirimanna]

On Dec 6, 2016 3:19 AM, "Prabath Siriwardana"  wrote:



On Thu, Dec 1, 2016 at 12:08 AM, Senthalan Kanagalingam 
wrote:

> ​When moving XACML from C4 to C5, we have concerned following key aspect
> to change and improve.
>
> 1. Remove multi tenancy from ​entitlement engine.
>
> In C4, we have tightly coupled with the multi tenancy. So in order to
> remove that, we refactored the entitlement engine and caching level. But in
> storing the policy, we are coupled with the registry and again there is a
> tenancy, but having different deployment that we are going to discuss in
> next, it will get rid of. So multi tenancy is already removed from the
> entitlement now.
>
> In balana we are not coupled with the tenant story already and we can go
> with current balana engine as it is. There may be improvement, but we are
> not evaluating that for now.
>
> 2. Write a File based deployer to the XACML.
>
> Since we are going to based on file based deployment for XACML, going to
> implement deployer module as that was introduced by the platform [1]. To
> load the deployable files into the memory, new XACML deployer will
> listening to the xacml deployer folder and will load it into the virtual
> store. This folder path is configurable to mounting to the common location
> in cluster environment.
>
> 3. Evaluate whether we need PAP in to the runtime instead of coming with
> developer portal.
>
> Currently C4 we have a PAP in IS for administrative perspective, but in C5
> we are going to have developer portal in separate, so we don't think to
> have this PAP in IS runtime. We have to think about this in developer
> portal. Are there any valid use cases that we must have PAP in runtime ?
>
> WDYT ?
>

Yes - that's right. Policy creating is not part of the IS UI - it will be
part of the tooling. Identity Server Admin is responsible for the deploying
of XACML policies to the server.


>
> 4. Mechanism to notify to cluster about policy changes to get reload the
> specific policy into the memory.
>
> In C4 we are doing this based in hazelcast notiifcation and in C5 we don't
> have any way to do this. We have to come with a solution for this
> notification based synchronizer not only for XAMCL , but for all the other
> features (may be other product as well) as well.
>
> ​5. ​Storing XACML metadata.
>
> ​Now C4 we have stored XACML in registry​ and we have a proper way to
> store metadata against each resources. But when we move to the file system,
> we have to either file based metadata model or equivalent db to each
> resource's metadata. Our suggestion was to have a separate meta file for
> each resource in the file system with the resource itself. WDYT ?
>

I doubt this is needed. AFAIR this was only used to help reverse look up.
We can skip this for the IS 6.0.0 as we are doing some research on this
area.


Yes , I agree, but we have to maintain policy status as well like
active/deactive , order ..etc...
So we should have some way to keep this. These data also per policy
metadata. How can we proceed then ?



>
> ​Are there any key aspect that we MUST concern with the XACML moving to
> the C5, then at least we can create redmine and address later.
>
> ​
>
> [1] - https://github.com/wso2/carbon-deployment ​
>
>
> ​
> --
> K.Senthalan,
> Software Engineering Intern,
> WSO2 Inc.
> Tel: +94771877466 <077%20187%207466>
> Email: senthalank...@cse.mrt.ac.lk
>



-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950 <(650)%20625-7950>

http://facilelogin.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving XACML to C5

[Prabath Siriwardana]

On Thu, Dec 1, 2016 at 12:08 AM, Senthalan Kanagalingam 
wrote:

> ​When moving XACML from C4 to C5, we have concerned following key aspect
> to change and improve.
>
> 1. Remove multi tenancy from ​entitlement engine.
>
> In C4, we have tightly coupled with the multi tenancy. So in order to
> remove that, we refactored the entitlement engine and caching level. But in
> storing the policy, we are coupled with the registry and again there is a
> tenancy, but having different deployment that we are going to discuss in
> next, it will get rid of. So multi tenancy is already removed from the
> entitlement now.
>
> In balana we are not coupled with the tenant story already and we can go
> with current balana engine as it is. There may be improvement, but we are
> not evaluating that for now.
>
> 2. Write a File based deployer to the XACML.
>
> Since we are going to based on file based deployment for XACML, going to
> implement deployer module as that was introduced by the platform [1]. To
> load the deployable files into the memory, new XACML deployer will
> listening to the xacml deployer folder and will load it into the virtual
> store. This folder path is configurable to mounting to the common location
> in cluster environment.
>
> 3. Evaluate whether we need PAP in to the runtime instead of coming with
> developer portal.
>
> Currently C4 we have a PAP in IS for administrative perspective, but in C5
> we are going to have developer portal in separate, so we don't think to
> have this PAP in IS runtime. We have to think about this in developer
> portal. Are there any valid use cases that we must have PAP in runtime ?
>
> WDYT ?
>

Yes - that's right. Policy creating is not part of the IS UI - it will be
part of the tooling. Identity Server Admin is responsible for the deploying
of XACML policies to the server.


>
> 4. Mechanism to notify to cluster about policy changes to get reload the
> specific policy into the memory.
>
> In C4 we are doing this based in hazelcast notiifcation and in C5 we don't
> have any way to do this. We have to come with a solution for this
> notification based synchronizer not only for XAMCL , but for all the other
> features (may be other product as well) as well.
>
> ​5. ​Storing XACML metadata.
>
> ​Now C4 we have stored XACML in registry​ and we have a proper way to
> store metadata against each resources. But when we move to the file system,
> we have to either file based metadata model or equivalent db to each
> resource's metadata. Our suggestion was to have a separate meta file for
> each resource in the file system with the resource itself. WDYT ?
>

I doubt this is needed. AFAIR this was only used to help reverse look up.
We can skip this for the IS 6.0.0 as we are doing some research on this
area.


>
> ​Are there any key aspect that we MUST concern with the XACML moving to
> the C5, then at least we can create redmine and address later.
>
> ​
>
> [1] - https://github.com/wso2/carbon-deployment ​
>
>
> ​
> --
> K.Senthalan,
> Software Engineering Intern,
> WSO2 Inc.
> Tel: +94771877466 <077%20187%207466>
> Email: senthalank...@cse.mrt.ac.lk
>



-- 
Thanks & Regards,
Prabath

Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena

Mobile : +1 650 625 7950

http://facilelogin.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Moving XACML to C5

[Senthalan Kanagalingam]

Hi Sidath,

Thank you for your feedback. Yes, we can use cluster communication for
database.

But we are planned to use file based storage to store the polices. If all
the nodes in the cluster use one directory, then their will be no need for
notifying other nodes about the policy change. Because when a node change a
policy in the directory, carbon-deployment will automatically notify to all
nodes.

Thanks and Regards,

On Sat, Dec 3, 2016 at 9:36 PM, Sidath Weerasinghe  wrote:

> Hi Senthalan,
>
> You can use RDBMS based cluster communication to notify to cluster about
> policy changes. [1]
>
> [1] https://wso2.org/jira/browse/MB-1704
>
>
>
>
> On Thu, Dec 1, 2016 at 1:38 PM, Senthalan Kanagalingam  > wrote:
>
>> ​When moving XACML from C4 to C5, we have concerned following key aspect
>> to change and improve.
>>
>> 1. Remove multi tenancy from ​entitlement engine.
>>
>> In C4, we have tightly coupled with the multi tenancy. So in order to
>> remove that, we refactored the entitlement engine and caching level. But in
>> storing the policy, we are coupled with the registry and again there is a
>> tenancy, but having different deployment that we are going to discuss in
>> next, it will get rid of. So multi tenancy is already removed from the
>> entitlement now.
>>
>> In balana we are not coupled with the tenant story already and we can go
>> with current balana engine as it is. There may be improvement, but we are
>> not evaluating that for now.
>>
>> 2. Write a File based deployer to the XACML.
>>
>> Since we are going to based on file based deployment for XACML, going to
>> implement deployer module as that was introduced by the platform [1]. To
>> load the deployable files into the memory, new XACML deployer will
>> listening to the xacml deployer folder and will load it into the virtual
>> store. This folder path is configurable to mounting to the common location
>> in cluster environment.
>>
>> 3. Evaluate whether we need PAP in to the runtime instead of coming with
>> developer portal.
>>
>> Currently C4 we have a PAP in IS for administrative perspective, but in
>> C5 we are going to have developer portal in separate, so we don't think to
>> have this PAP in IS runtime. We have to think about this in developer
>> portal. Are there any valid use cases that we must have PAP in runtime ?
>>
>> WDYT ?
>>
>> 4. Mechanism to notify to cluster about policy changes to get reload the
>> specific policy into the memory.
>>
>> In C4 we are doing this based in hazelcast notiifcation and in C5 we
>> don't have any way to do this. We have to come with a solution for this
>> notification based synchronizer not only for XAMCL , but for all the other
>> features (may be other product as well) as well.
>>
>> ​5. ​Storing XACML metadata.
>>
>> ​Now C4 we have stored XACML in registry​ and we have a proper way to
>> store metadata against each resources. But when we move to the file system,
>> we have to either file based metadata model or equivalent db to each
>> resource's metadata. Our suggestion was to have a separate meta file for
>> each resource in the file system with the resource itself. WDYT ?
>>
>> ​Are there any key aspect that we MUST concern with the XACML moving to
>> the C5, then at least we can create redmine and address later.
>>
>> ​
>>
>> [1] - https://github.com/wso2/carbon-deployment ​
>>
>>
>> ​
>> --
>> K.Senthalan,
>> Software Engineering Intern,
>> WSO2 Inc.
>> Tel: +94771877466 <+94%2077%20187%207466>
>> Email: senthalank...@cse.mrt.ac.lk
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thank You,
> Best Regards,
>
> Sidath Weerasinghe
>
>
> *Intern*
>
> *WSO2, Inc. *
>
> *lean . enterprise . middleware *
>
>
> *Mobile: +94719802550 <+94%2071%20980%202550>*
>
> *Email: *sid...@wso2.com
>
> Blog: https://medium.com/@sidath
>
> Linkedin: https://lk.linkedin.com/in/sidathweerasinghe
>



-- 
K.Senthalan,
Software Engineering Intern,
WSO2 Inc.
Tel: +94771877466
Email: senthalank...@cse.mrt.ac.lk
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Moving XACML to C5

[Senthalan Kanagalingam]

​When moving XACML from C4 to C5, we have concerned following key aspect to
change and improve.

1. Remove multi tenancy from ​entitlement engine.

In C4, we have tightly coupled with the multi tenancy. So in order to
remove that, we refactored the entitlement engine and caching level. But in
storing the policy, we are coupled with the registry and again there is a
tenancy, but having different deployment that we are going to discuss in
next, it will get rid of. So multi tenancy is already removed from the
entitlement now.

In balana we are not coupled with the tenant story already and we can go
with current balana engine as it is. There may be improvement, but we are
not evaluating that for now.

2. Write a File based deployer to the XACML.

Since we are going to based on file based deployment for XACML, going to
implement deployer module as that was introduced by the platform [1]. To
load the deployable files into the memory, new XACML deployer will
listening to the xacml deployer folder and will load it into the virtual
store. This folder path is configurable to mounting to the common location
in cluster environment.

3. Evaluate whether we need PAP in to the runtime instead of coming with
developer portal.

Currently C4 we have a PAP in IS for administrative perspective, but in C5
we are going to have developer portal in separate, so we don't think to
have this PAP in IS runtime. We have to think about this in developer
portal. Are there any valid use cases that we must have PAP in runtime ?

WDYT ?

4. Mechanism to notify to cluster about policy changes to get reload the
specific policy into the memory.

In C4 we are doing this based in hazelcast notiifcation and in C5 we don't
have any way to do this. We have to come with a solution for this
notification based synchronizer not only for XAMCL , but for all the other
features (may be other product as well) as well.

​5. ​Storing XACML metadata.

​Now C4 we have stored XACML in registry​ and we have a proper way to store
metadata against each resources. But when we move to the file system, we
have to either file based metadata model or equivalent db to each
resource's metadata. Our suggestion was to have a separate meta file for
each resource in the file system with the resource itself. WDYT ?

​Are there any key aspect that we MUST concern with the XACML moving to the
C5, then at least we can create redmine and address later.

​

[1] - https://github.com/wso2/carbon-deployment ​


​
-- 
K.Senthalan,
Software Engineering Intern,
WSO2 Inc.
Tel: +94771877466
Email: senthalank...@cse.mrt.ac.lk
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture