From Anil.Saldhana at redhat.com Fri Jan 10 12:51:28 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 10 Jan 2014 11:51:28 -0600 Subject: [security-dev] PicketLink 2.6.0.Beta2 is delayed a bit Message-ID: <52D03320.7000802@redhat.com> Hi All, we have run into some issues which is forcing us to delay 2.6.0.Beta2 a bit. The roadmap is here: (we are late) https://docs.jboss.org/author/display/PLINK/RoadMap+-+PicketLink+v2.5.3+and+Beyond Maybe 2-3 days. Regards, Anil From psilva at redhat.com Mon Jan 13 15:12:05 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 13 Jan 2014 15:12:05 -0500 (EST) Subject: [security-dev] PicketLink 2.6.0.Beta2 Released In-Reply-To: <1060017914.819368.1389643810043.JavaMail.root@redhat.com> Message-ID: <2096792584.821589.1389643925309.JavaMail.root@redhat.com> Hi All, Today we released PicketLink 2.6.0.Beta2. For more information, please visit our site: http://www.picketlink.org https://community.jboss.org/thread/236124 Documentation can be obtained from: http://docs.jboss.org/picketlink/2/latest Issues for this version: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310923&version=12323640 Regards. Pedro Igor From ggastald at redhat.com Mon Jan 13 15:15:50 2014 From: ggastald at redhat.com (George Gastaldi) Date: Mon, 13 Jan 2014 15:15:50 -0500 (EST) Subject: [security-dev] PicketLink 2.6.0.Beta2 Released In-Reply-To: <2096792584.821589.1389643925309.JavaMail.root@redhat.com> References: <2096792584.821589.1389643925309.JavaMail.root@redhat.com> Message-ID: <350E9A1E-474A-49C7-9937-9E1EBF3DD13F@redhat.com> Congrats! > Em 13/01/2014, ?s 18:12, Pedro Igor Silva escreveu: > > Hi All, > > Today we released PicketLink 2.6.0.Beta2. > > For more information, please visit our site: > > http://www.picketlink.org > https://community.jboss.org/thread/236124 > > Documentation can be obtained from: > > http://docs.jboss.org/picketlink/2/latest > > Issues for this version: > > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310923&version=12323640 > > > Regards. > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From olukas at redhat.com Fri Jan 17 02:43:02 2014 From: olukas at redhat.com (Ondra Lukas) Date: Fri, 17 Jan 2014 02:43:02 -0500 (EST) Subject: [security-dev] Java Security Policy with denying rules In-Reply-To: <1440842952.1454703.1389944490586.JavaMail.root@redhat.com> Message-ID: <1315294429.1454790.1389944582174.JavaMail.root@redhat.com> Hi, I've implemented Java Security Manager and Policy for using denying rules and I think that maybe someone will be interested in it. Standard Java Policy [1] uses only granting permissions and there are cases when denying rules are more comfortable than granting rules. I would like to know your opinion and get some feedback if you'll be interested. Project is called Prograde (Policy Rules Of GRanting And DEnying) and you can use it as maven artifact: net.sourceforge.pro-grade pro-grade 1.0 Project is also available through github [2] and some tests are in progradeTests project [3]. In the README files of these two github projects is some information about using policy with denying rules. Usage is similar as with standard policy, but you can write also deny entry (keyword "deny") instead of grant. There is a new entry named "priority" which is set to grant or deny value - it says whether grant or deny rule is used if they are in conflict. Some examples of policy files are used in [3]. I think that the main advantage of this type of policy rules and Prograde project is simplification of testing. Sometimes you want to know what behavior will your application have in case that some specific permission isn't granted. In this case you need to grant everything except that permission, so a denying rule is the best option. There are also some imperfections, but I think that they are not so important: - Prograde is not able to work with general expansion [4]. (property expansion works fine) - Path used in codebase entry must contain only a-z, A-Z, 0-9 and some symbols defined in encodeSpecialCharacters protected method of net.sourceforge.prograde.policy.ProgradePolicyFile class. I am planning to fix it in future releases. I hope Prograde will be helpful for somebody and I'll be happy for every feedback. Best regards, Ondrej Lukas [1] http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html [2] https://github.com/olukas/pro-grade [3] https://github.com/olukas/progradeTests [4] http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#GeneralExp From kpiwko at redhat.com Mon Jan 20 06:48:47 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 12:48:47 +0100 Subject: [security-dev] PicketLink 2.6.0.Beta2 Released In-Reply-To: <2096792584.821589.1389643925309.JavaMail.root@redhat.com> References: <1060017914.819368.1389643810043.JavaMail.root@redhat.com> <2096792584.821589.1389643925309.JavaMail.root@redhat.com> Message-ID: <20140120124847.614ae23d@kapy-ntb-x220> Hi, congrats for the release. If I'm about to try it out on top of EAP 6.2.0.GA, what should I do given the installer is not available? Thanks, Karel On Mon, 13 Jan 2014 15:12:05 -0500 (EST) Pedro Igor Silva wrote: > Hi All, > > Today we released PicketLink 2.6.0.Beta2. > > For more information, please visit our site: > > http://www.picketlink.org > https://community.jboss.org/thread/236124 > > Documentation can be obtained from: > > http://docs.jboss.org/picketlink/2/latest > > Issues for this version: > > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310923&version=12323640 > > > Regards. > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev From psilva at redhat.com Tue Jan 21 05:50:03 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 21 Jan 2014 05:50:03 -0500 (EST) Subject: [security-dev] PicketLink 2.6.0.Beta2 Released In-Reply-To: <20140120124847.614ae23d@kapy-ntb-x220> References: <1060017914.819368.1389643810043.JavaMail.root@redhat.com> <2096792584.821589.1389643925309.JavaMail.root@redhat.com> <20140120124847.614ae23d@kapy-ntb-x220> Message-ID: <1061820892.7267953.1390301403116.JavaMail.root@redhat.com> Hi Karel, You can try the latest installer[1] and after updating your EAP distribution you just replace the jars with 2.6.0.Beta2. [1] http://downloads.jboss.org/picketlink/2/2.5.3.Beta1/picketlink-1.2.2.Final-installer.zip ----- Original Message ----- From: "Karel Piwko" To: security-dev at lists.jboss.org Sent: Monday, January 20, 2014 9:48:47 AM Subject: Re: [security-dev] PicketLink 2.6.0.Beta2 Released Hi, congrats for the release. If I'm about to try it out on top of EAP 6.2.0.GA, what should I do given the installer is not available? Thanks, Karel On Mon, 13 Jan 2014 15:12:05 -0500 (EST) Pedro Igor Silva wrote: > Hi All, > > Today we released PicketLink 2.6.0.Beta2. > > For more information, please visit our site: > > http://www.picketlink.org > https://community.jboss.org/thread/236124 > > Documentation can be obtained from: > > http://docs.jboss.org/picketlink/2/latest > > Issues for this version: > > https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310923&version=12323640 > > > Regards. > Pedro Igor > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev From Anil.Saldhana at redhat.com Wed Jan 22 10:24:43 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Wed, 22 Jan 2014 09:24:43 -0600 Subject: [security-dev] Authentication Risks and Mitigation Strategies Message-ID: <52DFE2BB.7080806@redhat.com> http://docs.oasis-open.org/trust-el/trust-el-framework/v1.0/csprd01/trust-el-framework-v1.0-csprd01.html Section 3.2 From sdouglas at redhat.com Thu Jan 23 08:14:35 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 23 Jan 2014 08:14:35 -0500 (EST) Subject: [security-dev] Moving picketbox to Github In-Reply-To: <1007195282.4874158.1390482815608.JavaMail.root@redhat.com> Message-ID: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> Hi, Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. Stuart From Anil.Saldhana at redhat.com Thu Jan 23 08:17:23 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 23 Jan 2014 07:17:23 -0600 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> Message-ID: <52E11663.70104@redhat.com> Hi Stuart, we have a github organization called picketbox. http://github.com/picketbox Planning to use that for WildFly9+ The project is picketbox container. Regards, Anil On 01/23/2014 07:14 AM, Stuart Douglas wrote: > Hi, > > Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. > > Stuart > From Anil.Saldhana at redhat.com Thu Jan 23 10:04:22 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 23 Jan 2014 09:04:22 -0600 Subject: [security-dev] Community production App using PicketLink Framework Message-ID: <52E12F76.4040907@redhat.com> https://twitter.com/pkkamos/status/426280505257230336 Apart from PicketLink for security, it uses DeltaSpike and WildFlyAS. From darran.lofthouse at jboss.com Thu Jan 23 10:14:56 2014 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 23 Jan 2014 15:14:56 +0000 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> Message-ID: <52E131F0.7000703@jboss.com> +1 Please make the move - getting it moved is a one off task and once moved it is one less project we need SVN for ;-) On 23/01/14 13:14, Stuart Douglas wrote: > Hi, > > Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. > > Stuart > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > From Anil.Saldhana at redhat.com Thu Jan 23 11:02:53 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 23 Jan 2014 10:02:53 -0600 Subject: [security-dev] Moving picketbox to Github In-Reply-To: <52E131F0.7000703@jboss.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> Message-ID: <52E13D2D.3010702@redhat.com> https://github.com/picketbox/picketbox-container This has been there for a few months now. I am trying to dodge my memory as to why we did not use it to upgrade in WF8. Maybe Stefan remembers. I guess it was something to do with the plan to discard very old code and refactor it to just include what is necessary for WF. I think we did not have enough time to go with the plan yet. Definitely will be the PBox repo in WF9+. On 01/23/2014 09:14 AM, Darran Lofthouse wrote: > +1 Please make the move - getting it moved is a one off task and once > moved it is one less project we need SVN for ;-) > > > On 23/01/14 13:14, Stuart Douglas wrote: >> Hi, >> >> Are there any plans to move Picketbox to github? It makes it much easer for people outside the security team to submit fixes etc. >> >> Stuart >> From sdouglas at redhat.com Thu Jan 23 15:49:02 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 23 Jan 2014 15:49:02 -0500 (EST) Subject: [security-dev] Moving picketbox to Github In-Reply-To: <52E13D2D.3010702@redhat.com> References: <778405030.4874586.1390482875697.JavaMail.root@redhat.com> <52E131F0.7000703@jboss.com> <52E13D2D.3010702@redhat.com> Message-ID: <2112123432.5120806.1390510142991.JavaMail.root@redhat.com> IMHO it would be much easier to just move to github, then remove the old code. The two tasks are not really related, and it will probably actually be easier to do once the move has happened. Stuart. ----- Original Message ----- > From: "Anil Saldhana" > To: security-dev at lists.jboss.org > Sent: Thursday, 23 January, 2014 5:02:53 PM > Subject: Re: [security-dev] Moving picketbox to Github > > https://github.com/picketbox/picketbox-container > > This has been there for a few months now. I am trying to dodge my > memory as to why we did not use it to > upgrade in WF8. Maybe Stefan remembers. > > I guess it was something to do with the plan to discard very old code > and refactor it to just include what is necessary for WF. > I think we did not have enough time to go with the plan yet. > > Definitely will be the PBox repo in WF9+. > > > On 01/23/2014 09:14 AM, Darran Lofthouse wrote: > > +1 Please make the move - getting it moved is a one off task and once > > moved it is one less project we need SVN for ;-) > > > > > > On 23/01/14 13:14, Stuart Douglas wrote: > >> Hi, > >> > >> Are there any plans to move Picketbox to github? It makes it much easer > >> for people outside the security team to submit fixes etc. > >> > >> Stuart > >> > > _______________________________________________ > security-dev mailing list > security-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > From asaldhan at redhat.com Tue Jan 28 13:54:25 2014 From: asaldhan at redhat.com (Anil Saldhana) Date: Tue, 28 Jan 2014 13:54:25 -0500 (EST) Subject: [security-dev] Java8: TLS 1.2 default Message-ID: blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/security-dev/attachments/20140128/735cfac3/attachment.html From Anil.Saldhana at redhat.com Thu Jan 30 08:49:02 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 30 Jan 2014 07:49:02 -0600 Subject: [security-dev] Permission API, Implementation and Quickstart Message-ID: <52EA584E.7060905@redhat.com> Hi Shane/Pedro, can we have a discussion on the Permission API,Implementation and Quickstart on this mailing list to see if we have any feedback from the other teams? Since it will be an important feature for the next beta release, I just want to get people to have a peek at it. ;) Regards, Anil From psilva at redhat.com Thu Jan 30 09:29:47 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 30 Jan 2014 09:29:47 -0500 (EST) Subject: [security-dev] Permission API, Implementation and Quickstart In-Reply-To: <52EA584E.7060905@redhat.com> References: <52EA584E.7060905@redhat.com> Message-ID: <14740503.13661527.1391092187558.JavaMail.root@redhat.com> I did see Shane's last changes to our quickstarts [1] and documentation [2]. [1] - https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-authorization-acl [2] - http://docs.jboss.org/picketlink/2/latest/reference/html/ch10.html They can give a good overview. ----- Original Message ----- From: "Anil Saldhana" To: security-dev at lists.jboss.org Sent: Thursday, January 30, 2014 11:49:02 AM Subject: [security-dev] Permission API, Implementation and Quickstart Hi Shane/Pedro, can we have a discussion on the Permission API,Implementation and Quickstart on this mailing list to see if we have any feedback from the other teams? Since it will be an important feature for the next beta release, I just want to get people to have a peek at it. ;) Regards, Anil _______________________________________________ security-dev mailing list security-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev From Anil.Saldhana at redhat.com Thu Jan 30 09:54:47 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Thu, 30 Jan 2014 08:54:47 -0600 Subject: [security-dev] Permission API, Implementation and Quickstart In-Reply-To: <14740503.13661527.1391092187558.JavaMail.root@redhat.com> References: <52EA584E.7060905@redhat.com> <14740503.13661527.1391092187558.JavaMail.root@redhat.com> Message-ID: <52EA67B7.5040707@redhat.com> I had a brief chat with Shane this morning. He said there was an issue with the quickstart due to a potential WildFly issue. He would like to try with the latest WildFly version. This is a good start at fine grained authorization. On 01/30/2014 08:29 AM, Pedro Igor Silva wrote: > I did see Shane's last changes to our quickstarts [1] and documentation [2]. > > [1] - https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-authorization-acl > [2] - http://docs.jboss.org/picketlink/2/latest/reference/html/ch10.html > > They can give a good overview. > > ----- Original Message ----- > From: "Anil Saldhana" > To: security-dev at lists.jboss.org > Sent: Thursday, January 30, 2014 11:49:02 AM > Subject: [security-dev] Permission API, Implementation and Quickstart > > Hi Shane/Pedro, > can we have a discussion on the Permission API,Implementation and > Quickstart on this mailing list to see if we have any feedback from the > other teams? Since it will be an important feature for the next beta > release, I just want to get people to have a peek at it. ;) > > Regards, > Anil From Anil.Saldhana at redhat.com Fri Jan 31 10:40:22 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 09:40:22 -0600 Subject: [security-dev] Entitlements Concept Message-ID: <52EBC3E6.9040508@redhat.com> Hi All, any objections to getting the Entitlements Manager concept into PicketLink Authorization? That way we cover all based with both Fine Grained Authorization (Permissions API/Implementation) as well as download of entitlements. My previous prototype: https://docs.jboss.org/author/display/SECURITY/EntitlementsManager (there are bugs in the test case which I will fix) While the FGA is what I call the Enforcement Model, the EntitlementsManager concept is what I call the Entitlement Model. I am currently writing a specification at OASIS for this: https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz Regards, Anil From Anil.Saldhana at redhat.com Fri Jan 31 10:43:09 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 09:43:09 -0600 Subject: [security-dev] Entitlements Concept In-Reply-To: <52EBC3E6.9040508@redhat.com> References: <52EBC3E6.9040508@redhat.com> Message-ID: <52EBC48D.8000706@redhat.com> The idea is if rather than make 100 enforcement (Access Checks), you make one call and download the entitlements and then do local authorization checks. As an example, there is a mobile phone that has a rich native app. It connects to a server and downloads the entitlements on the fly. That way it can make local decisions as to what the permissions are, rather than make individual server access checks. Useful in environments such as financial apps. On 01/31/2014 09:40 AM, Anil Saldhana wrote: > Hi All, > any objections to getting the Entitlements Manager concept into > PicketLink Authorization? That way we cover all based with both Fine > Grained Authorization (Permissions API/Implementation) as well as > download of entitlements. > My previous prototype: > https://docs.jboss.org/author/display/SECURITY/EntitlementsManager > (there are bugs in the test case which I will fix) > > While the FGA is what I call the Enforcement Model, the > EntitlementsManager concept is what I call the Entitlement Model. > > I am currently writing a specification at OASIS for this: > https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz > > Regards, > Anil From Anil.Saldhana at redhat.com Fri Jan 31 10:45:33 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 09:45:33 -0600 Subject: [security-dev] Entitlements Concept In-Reply-To: <52EBC48D.8000706@redhat.com> References: <52EBC3E6.9040508@redhat.com> <52EBC48D.8000706@redhat.com> Message-ID: <52EBC51D.7020204@redhat.com> Another example would be something like Drools Guvnor where the display of assets needs to be regulated. So instead of checking on individual asset check, one call is made for the entire permission collection and the UI is rendered faster. On 01/31/2014 09:43 AM, Anil Saldhana wrote: > The idea is if rather than make 100 enforcement (Access Checks), you > make one call and download > the entitlements and then do local authorization checks. > > As an example, there is a mobile phone that has a rich native app. It > connects to a server and downloads > the entitlements on the fly. That way it can make local decisions as to > what the permissions are, rather than > make individual server access checks. Useful in environments such as > financial apps. > > On 01/31/2014 09:40 AM, Anil Saldhana wrote: >> Hi All, >> any objections to getting the Entitlements Manager concept into >> PicketLink Authorization? That way we cover all based with both Fine >> Grained Authorization (Permissions API/Implementation) as well as >> download of entitlements. >> My previous prototype: >> https://docs.jboss.org/author/display/SECURITY/EntitlementsManager >> (there are bugs in the test case which I will fix) >> >> While the FGA is what I call the Enforcement Model, the >> EntitlementsManager concept is what I call the Entitlement Model. >> >> I am currently writing a specification at OASIS for this: >> https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz >> >> Regards, >> Anil >> From Anil.Saldhana at redhat.com Fri Jan 31 10:48:53 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 09:48:53 -0600 Subject: [security-dev] Permission API, Implementation and Quickstart In-Reply-To: <52EA67B7.5040707@redhat.com> References: <52EA584E.7060905@redhat.com> <14740503.13661527.1391092187558.JavaMail.root@redhat.com> <52EA67B7.5040707@redhat.com> Message-ID: <52EBC5E5.6010806@redhat.com> Also good time to move the "permissions" module away from prototype into modules. On 01/30/2014 08:54 AM, Anil Saldhana wrote: > I had a brief chat with Shane this morning. He said there was an issue > with the quickstart due to > a potential WildFly issue. He would like to try with the latest WildFly > version. > > This is a good start at fine grained authorization. > > On 01/30/2014 08:29 AM, Pedro Igor Silva wrote: >> I did see Shane's last changes to our quickstarts [1] and documentation [2]. >> >> [1] - https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-authorization-acl >> [2] - http://docs.jboss.org/picketlink/2/latest/reference/html/ch10.html >> >> They can give a good overview. >> >> ----- Original Message ----- >> From: "Anil Saldhana" >> To: security-dev at lists.jboss.org >> Sent: Thursday, January 30, 2014 11:49:02 AM >> Subject: [security-dev] Permission API, Implementation and Quickstart >> >> Hi Shane/Pedro, >> can we have a discussion on the Permission API,Implementation and >> Quickstart on this mailing list to see if we have any feedback from the >> other teams? Since it will be an important feature for the next beta >> release, I just want to get people to have a peek at it. ;) >> >> Regards, >> Anil >> From psilva at redhat.com Fri Jan 31 11:05:40 2014 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 31 Jan 2014 11:05:40 -0500 (EST) Subject: [security-dev] Entitlements Concept In-Reply-To: <52EBC51D.7020204@redhat.com> References: <52EBC3E6.9040508@redhat.com> <52EBC48D.8000706@redhat.com> <52EBC51D.7020204@redhat.com> Message-ID: <1792990746.14471119.1391184340505.JavaMail.root@redhat.com> In some way we support that, one just need to use the Permission API to obtain the permissions and return them back using JSON, for example. Maybe once we start working with the REST module we can provide that OOTB. But how entitlements relates with XACML ? Is it a enabler ? ----- Original Message ----- From: "Anil Saldhana" To: security-dev at lists.jboss.org Sent: Friday, January 31, 2014 1:45:33 PM Subject: Re: [security-dev] Entitlements Concept Another example would be something like Drools Guvnor where the display of assets needs to be regulated. So instead of checking on individual asset check, one call is made for the entire permission collection and the UI is rendered faster. On 01/31/2014 09:43 AM, Anil Saldhana wrote: > The idea is if rather than make 100 enforcement (Access Checks), you > make one call and download > the entitlements and then do local authorization checks. > > As an example, there is a mobile phone that has a rich native app. It > connects to a server and downloads > the entitlements on the fly. That way it can make local decisions as to > what the permissions are, rather than > make individual server access checks. Useful in environments such as > financial apps. > > On 01/31/2014 09:40 AM, Anil Saldhana wrote: >> Hi All, >> any objections to getting the Entitlements Manager concept into >> PicketLink Authorization? That way we cover all based with both Fine >> Grained Authorization (Permissions API/Implementation) as well as >> download of entitlements. >> My previous prototype: >> https://docs.jboss.org/author/display/SECURITY/EntitlementsManager >> (there are bugs in the test case which I will fix) >> >> While the FGA is what I call the Enforcement Model, the >> EntitlementsManager concept is what I call the Entitlement Model. >> >> I am currently writing a specification at OASIS for this: >> https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz >> >> Regards, >> Anil >> _______________________________________________ security-dev mailing list security-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev From Anil.Saldhana at redhat.com Fri Jan 31 11:07:08 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 10:07:08 -0600 Subject: [security-dev] Entitlements Concept In-Reply-To: <1792990746.14471119.1391184340505.JavaMail.root@redhat.com> References: <52EBC3E6.9040508@redhat.com> <52EBC48D.8000706@redhat.com> <52EBC51D.7020204@redhat.com> <1792990746.14471119.1391184340505.JavaMail.root@redhat.com> Message-ID: <52EBCA2C.7060708@redhat.com> On 01/31/2014 10:05 AM, Pedro Igor Silva wrote: > In some way we support that, one just need to use the Permission API to obtain the permissions and return them back using JSON, for example. > > Maybe once we start working with the REST module we can provide that OOTB. > > But how entitlements relates with XACML ? Is it a enabler ? XACML is still and enforcement model. You get answers (Y/N). Rather than - here is the Context (user, role, group, time, IP) and now give me the relevant permissions. > ----- Original Message ----- > From: "Anil Saldhana" > To: security-dev at lists.jboss.org > Sent: Friday, January 31, 2014 1:45:33 PM > Subject: Re: [security-dev] Entitlements Concept > > Another example would be something like Drools Guvnor where the display > of assets needs to be regulated. So instead of checking on individual asset > check, one call is made for the entire permission collection and the UI > is rendered faster. > > On 01/31/2014 09:43 AM, Anil Saldhana wrote: >> The idea is if rather than make 100 enforcement (Access Checks), you >> make one call and download >> the entitlements and then do local authorization checks. >> >> As an example, there is a mobile phone that has a rich native app. It >> connects to a server and downloads >> the entitlements on the fly. That way it can make local decisions as to >> what the permissions are, rather than >> make individual server access checks. Useful in environments such as >> financial apps. >> >> On 01/31/2014 09:40 AM, Anil Saldhana wrote: >>> Hi All, >>> any objections to getting the Entitlements Manager concept into >>> PicketLink Authorization? That way we cover all based with both Fine >>> Grained Authorization (Permissions API/Implementation) as well as >>> download of entitlements. >>> My previous prototype: >>> https://docs.jboss.org/author/display/SECURITY/EntitlementsManager >>> (there are bugs in the test case which I will fix) >>> >>> While the FGA is what I call the Enforcement Model, the >>> EntitlementsManager concept is what I call the Entitlement Model. >>> >>> I am currently writing a specification at OASIS for this: >>> https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz >>> >>> Regards, >>> Anil >>> >>> From Anil.Saldhana at redhat.com Fri Jan 31 16:28:52 2014 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 31 Jan 2014 15:28:52 -0600 Subject: [security-dev] Entitlements Concept In-Reply-To: <1792990746.14471119.1391184340505.JavaMail.root@redhat.com> References: <52EBC3E6.9040508@redhat.com> <52EBC48D.8000706@redhat.com> <52EBC51D.7020204@redhat.com> <1792990746.14471119.1391184340505.JavaMail.root@redhat.com> Message-ID: <52EC1594.8080702@redhat.com> On 01/31/2014 10:05 AM, Pedro Igor Silva wrote: > In some way we support that, one just need to use the Permission API to obtain the permissions and return them back using JSON, for example. Think so. > Maybe once we start working with the REST module we can provide that OOTB. Think so. > But how entitlements relates with XACML ? Is it a enabler ? > ----- Original Message ----- > From: "Anil Saldhana" > To: security-dev at lists.jboss.org > Sent: Friday, January 31, 2014 1:45:33 PM > Subject: Re: [security-dev] Entitlements Concept > > Another example would be something like Drools Guvnor where the display > of assets needs to be regulated. So instead of checking on individual asset > check, one call is made for the entire permission collection and the UI > is rendered faster. > > On 01/31/2014 09:43 AM, Anil Saldhana wrote: >> The idea is if rather than make 100 enforcement (Access Checks), you >> make one call and download >> the entitlements and then do local authorization checks. >> >> As an example, there is a mobile phone that has a rich native app. It >> connects to a server and downloads >> the entitlements on the fly. That way it can make local decisions as to >> what the permissions are, rather than >> make individual server access checks. Useful in environments such as >> financial apps. >> >> On 01/31/2014 09:40 AM, Anil Saldhana wrote: >>> Hi All, >>> any objections to getting the Entitlements Manager concept into >>> PicketLink Authorization? That way we cover all based with both Fine >>> Grained Authorization (Permissions API/Implementation) as well as >>> download of entitlements. >>> My previous prototype: >>> https://docs.jboss.org/author/display/SECURITY/EntitlementsManager >>> (there are bugs in the test case which I will fix) >>> >>> While the FGA is what I call the Enforcement Model, the >>> EntitlementsManager concept is what I call the Entitlement Model. >>> >>> I am currently writing a specification at OASIS for this: >>> https://www.oasis-open.org/committees/document.php?document_id=52098&wg_abbrev=cloudauthz >>> >>> Regards, >>> Anil >>> >>>