[Fiware-security] RBAC

[DANGERVILLE Cyril]

Hello,
Sorry for the late reply, I had to check a few things with my colleagues regarding the current status of RBAC support in our XACML engine. So, in our Thales XACML Asset, we have a preliminary support of the Core and hierarchical role based access control (RBAC) profile of XACML v2.0. I say "preliminary" for the following reasons:

1.       The Role Assignment/Enablement part of the profile is not supported. Therefore, you have to provide your own solution for (de-)assigning role to users, and role management in general: Identity Management GE, LDAP directory, etc. Our asset only provides for administration and enforcement of RBAC policies (defining permissions for each role, and role hierarchies). Then, you need to make sure our asset's PDP is able to get the roles of the user when requesting authorization. There are two options:

a.       The PEP sends the user role attributes directly in the XACML authorization request to the PDP.

b.      Add a specific connector to the PDP, usually called "attribute finder", that is able to get the user role attributes from your role management solution, based on a user ID attribute sent  by the PEP in the XACML request. In this case, there may be some effort involved to develop such a connector.

2.       Configuring RBAC policies with the API (RESTful) is supported for Core RBAC but *NOT for Hierarchical RBAC* ; in the latter case, only RPS (Role <PolicySet>, see XACML RBAC profile for definition) may be configured via the API, PPS (Permission <PolicySet>) have to be manually added/edited by the administrator locally on the filesystem where  the XACML Authorization Service of our asset is deployed.

3.       We have tested RBAC policies implementing at most one-level role hierarchy only so far (e.g. Role1 senior to Role2). Depending on your use case, we could test more (Role1 senior to Role2 senior to Role3, etc.) if really necessary.

If all this is acceptable for your use case and this is not too urgent (what's the time frame?), you can send me examples of the RBAC policies that you want to implement, in natural or some formal language (easily understandable), so that I can better assess whether it is feasible or not with our asset.

Thanks.

Regards,
CD


De : fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] De la part de Seidl, Robert (NSN - DE/Munich)
Envoyé : jeudi 16 mai 2013 16:32
À : Fiware-security at lists.fi-ware.eu
Objet : Re: [Fiware-security] RBAC

Hi all again,
we had one more telco with the use case project and they are really looking for an RBAC system.
Since not all partners have answered to my initial email, maybe there is one RBAC solution we could offer?

Many thanks
Robert

From: ext Susana Gonzalez Zarzosa [mailto:susana.gzarzosa at atosresearch.eu]
Sent: Tuesday, May 14, 2013 5:15 PM
To: Seidl, Robert (NSN - DE/Munich)
Subject: RE: [Fiware-security] RBAC

Hi Robert,

No, our enabler doesn't have RBAC integrated.

Best regards,
  Susana

From: fiware-security-bounces at lists.fi-ware.eu<mailto:fiware-security-bounces at lists.fi-ware.eu> [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of Seidl, Robert (NSN - DE/Munich)
Sent: martes, 14 de mayo de 2013 13:25
To: ext BISSON Pascal; ext GIDOIN Daniel
Cc: Fiware-security at lists.fi-ware.eu<mailto:Fiware-security at lists.fi-ware.eu>
Subject: [Fiware-security] RBAC

Hi all,
does someone plan to provide RBAC in FI-WARE?
I understood that it was planned by Thales, than decided not to provide it. Right?

Is there some other enabler who has RBAC integrated?

Background for this questions is that we got an requirement from a use case project.

Greetings
Robert


------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive
this e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos
group liability cannot be triggered for the message content. Although
the sender endeavours to maintain a computer virus-free network,
the sender does not warrant that this transmission is virus-free and
will not be liable for any damages resulting from any virus transmitted.

Este mensaje y los ficheros adjuntos pueden contener informacion confidencial
destinada solamente a la(s) persona(s) mencionadas anteriormente
pueden estar protegidos por secreto profesional.
Si usted recibe este correo electronico por error, gracias por informar
inmediatamente al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
no se hace responsable por su contenido. Su contenido no constituye ningun
compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes.
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no sera responsable de cualesquiera
danos que puedan resultar de una transmision de virus.
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20130517/b2eb0116/attachment.html>