On 3 September 2014 22:13, GESCONSULTOR - Óscar Bou <[email protected]> wrote:
> Hi to all. > > I see REALLY great work made on the new Authentication and Authorization > module on the Isis AddOns Github repository at [1]. > > It's the most cool impelmentation of a "generic" RBAC "domain" (in the DDD > sense) I've seen ready for integrating, so it's a really powerful weapon > for all us. > > Thanks!! > glad you like it! > > By the fact, my only doubt is how two conflicting permissions inherited > from different roles acquire prevalence. Normally, the more restrictive one > takes precedence (i.e., if any role "VETOES" - in the security add-on > terminology -) access to any feature - property, collection or action - it > should take precedence. > > I could easily refactor so that the algorithm for comparing permissions is factored out to a substitutable domain service. > > Also on [2] I don't find also any "priority" if any conflict is found on > permissions. > > OK, is that a common design... to have a priority and use the permission with the highest number to resolve conflicts? I guess that makes sense. Even so, there would still be the need to deal with a two permissions that have the same priority, so a substitutable algorithm would still be needed, I think? Gonna work on this today, so let me know your preferences. Cheers Dan > Any help on it ? > > Thanks again !!! > > Oscar > > > [1] https://github.com/isisaddons/isis-module-security > > [2] > https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/permission/ApplicationPermissions.java > > > El 31/07/2014, a las 09:00, GESCONSULTOR - Óscar Bou < > [email protected]> escribió: > > Really nice to hear! > > It will be extremely useful for most projects and a great differentiator > for any other dev platforms out there. > > Thanks, Jeroen! If you want to contrast any thoughts, test concepts, etc. > this August I will have a "bit more" time outside of our current project. > > > Regards, > > Oscar > > > El 31/07/2014, a las 08:44, Dan Haywood <[email protected]> > escribió: > > Jeroen has started implementing said RBAC module, and we also have a > related requirement to support multi-tenancy... ie we need a domain concept > of "User" somewhere, which is in its own subdomain but that an be managed > through Isis itself. > > Intention is to make this a deliverable, in some form, for 1.7.0; as you > said, Oscar, there was a lot of interest in this at IsisCon. > > Cheers > Dan > > > > On 31 July 2014 07:41, GESCONSULTOR - Óscar Bou <[email protected]> > wrote: > >> >> Hi to all. >> >> I think Dan's proposal is the best implementation possible, as it would >> not be embedded on the Domain, which would imply that could, for example, >> being configured by an admin through a UI. >> >> This is related with an Isis Authorization module we talked about on >> IsisCon, considering things like a RBAC style (see [1], [2] for Shiro >> related materials; [3] [4] for RBAC generic introduction). >> >> Nearly all business applications will "suffer" for implementing this >> requisite, so it's a good candidate for a generic Isis module. >> >> Thanks, >> >> Oscar >> >> [1] >> https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html >> >> [2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html >> >> [3] http://csrc.nist.gov/groups/SNS/rbac/ >> >> [4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf >> >> >> >> El 30/07/2014, a las 23:37, Dan Haywood <[email protected]> >> escribió: >> >> >> Hmm, not particularly keen on this suggestion... having role names >> embedded >> in annotations isn't a good idea, I think. >> >> For myself, I'd rather that this requirement was handled in a >> cross-cutting >> fashoin, through some sort of extension to the Isis' authorizor API. >> >> However, to solve this issue properly, I think we might need to extend >> Isis' security model somewhat. Right now in the authorizor we check if a >> given user (via their roles) can view/use each of an object's members >> (properties/collections/actions) but we don't have the concept of checking >> if the user can view the object at all. >> >> If we did introduce this idea (of object-level checks), then we could also >> implement some sort of plug-in point for the authorizor such that >> instance-based authorizers (eg in a chain of responsibility pattern) could >> be added to supplement Isis' usual class-based authorizors. >> >> I know this design would work because the Naked Objects "sister project" >> (on .NET) works this way. >> >> Hopefully that makes some sort of sense.... thoughts, anyone? >> >> Dan >> >> >> >> >> On 29 July 2014 22:56, matias nahuel heredia <[email protected]> >> wrote: >> >> El 29/07/14 08:16, Dan Haywood escribió: >> >> On 29 July 2014 02:28, matias nahuel heredia <[email protected]> >> >> wrote: >> >> hi Dan!! >> >> how can i fix this vulnerability in Apache isis? >> https://www.youtube.com/watch?v=AghmbcVE710 >> >> >> thanks for recording this, helps explain the issue. >> >> What we're talking about here is per-instance security... the idea that >> some users shouldn't be able to access some object instances (even though >> they do in general have access to other instances of a given class type, >> such as ToDoItem). >> >> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle >> callback (on ToDoItem itself) and have it thrown an exception if the >> object >> should not be accessible. Then, the ExceptionRecognizer can be used to >> translate this exception into a user-friendly error message. If the >> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException >> then this is already detected by the default implementation of >> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo >> rJdoObjectStore): >> >> >> final String ownedBy = getOwnedBy(); >> final String currentUser = container.getUser().getName(); >> if(!ownedBy.equals(currentUser)) { >> throw new JDOObjectNotFoundException("No such object"); >> } >> >> >> This code results in a redirect to the error page with a message: "Unable >> to load object. Has it been deleted by someone else? No such object". >> The "Unable to load object. Has it been deleted by someone else?" bit >> comes >> from the ExceptionRecognizer, the "No such object" comes from the loaded() >> method. >> >> I can think of two improvements. >> >> First, it would be to move this cross-cutting concern out of the entity >> (ToDoItem) and into some single subscriber that could do this sort of >> verification for all classes. We do have a ticket [1] to do this, I'll >> bring it forward to tackle in the next release 1.7.0. >> >> Second, the stack trace shown by Isis is rather ugly and also leaks the >> information that there is an object with the given identifier (even if the >> object itself isn't shown). So perhaps the ExceptionRecognizer needs to >> become more sophisticated such that the stack trace will be suppressed in >> some cases. >> >> I've raised a ticket for this requirement [2], citing this thread [3] >> >> Let me know your thoughts on the above. >> >> Thanks >> Dan >> >> >> [1] https://issues.apache.org/jira/browse/ISIS-803 >> [2] https://issues.apache.org/jira/browse/ISIS-846 >> >> i think the better way to validate this is the creation of metanotation >> >> in the Framework >> like that >> @forUser(name="getOwnedBy",allfor="role1,role2") >> public class NameClass >> { >> >> >> } >> >> >> >> Óscar Bou Bou >> Responsable de Producto >> Auditor Jefe de Certificación ISO 27001 en BSI >> CISA, CRISC, APMG ISO 20000, ITIL-F >> >> <contactenos.html.gif> 902 900 231 / 620 267 520 >> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou >> >> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou >> >> <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/> >> >> <gesconsultor_logo_blue_email.png> >> >> >> Este mensaje y los ficheros anexos son confidenciales. Los mismos >> contienen información reservada que no puede ser difundida. Si usted ha >> recibido este correo por error, tenga la amabilidad de eliminarlo de su >> sistema y avisar al remitente mediante reenvío a su dirección electrónica; >> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. >> Su dirección de correo electrónico junto a sus datos personales constan >> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la >> de mantener el contacto con Ud. Si quiere saber de qué información >> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo >> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a >> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, >> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 >> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o >> sus archivos adjuntos no contengan virus informáticos, y en caso que los >> tuvieran eliminarlos. >> >> >> >> >> >> > > > *Óscar Bou Bou* > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > <contactenos.html.gif> 902 900 231 / 620 267 520 > <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou > > <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou > > <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/> > > <gesconsultor_logo_blue_email.png> > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > > > > *Óscar Bou Bou* > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > 902 900 231 / 620 267 520 > http://www.twitter.com/oscarbou > > http://es.linkedin.com/in/oscarbou > > http://www.GesConsultor.com <http://www.gesconsultor.com/> > > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > >
