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
