Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Major
-
Resolution: Done
-
Fix Version/s: Sprint 4.2.3, 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:None
-
HD-Chapter:Security
-
HD-Enabler:AuthZForce
Description
Hello Tran,
I am currently checking that the attribute finder module works with the latest version of KeyRock running at:
https://account.lab.fiware.org/home
I'll send an example of configuration to you by Friday EOB.
Be aware that this attribute finder works with the last R3 release of the GEi (v3.3.3 released 2014-03-31 to be accurate) deployed currently on the global instance (az.testbed.fi-ware.eu). But we do not plan to make it compatible with the new release 4.1 and later anymore. I am saying that in case you want to migrate to the new version. Indeed, starting with release 4.1, the preferred alternative is to rely on the PEP to get the user attributes from the Identity Manager (e.g. KeyRock), based on the token, and provide these attributes to the Authorization PDP (in XACML request) instead of the raw OAuth token. This is why the PEP Proxy reference implementation (Wilma, by UPM) will provide this feature in next release 4.2:
http://catalogue.fi-ware.org/enablers/pep-proxy-wilma
Maybe you are already using such proxy for authentication.
Regards,
Cyril
> ----Message d'origine----
> De : DANGERVILLE Cyril
> Envoyé : jeudi 5 février 2015 18:36
> À : Tran Quang Thanh
> Objet : RE: Authorize PDP GE
>
> Dear Tran,
> The FIWARE coordination team now requires that all requests for
> technical support on GEs be submitted to the fiware-tech-help mailing
> list. Can you re-submit your request to this address?
> fiware-tech-help@lists.fi-ware.org
>
> Thank you,
> Cyril
>
> –
> Cyril DANGERVILLE, Thales Services
> FIWARE Phase II / WP1.7 Security (WPA), T1.7.2 Identity & Access
> Management (Contributor), Authorization PDP (ex-Access Control) GE
> Owner
>
> > ----Message d'origine----
> > De : Tran Quang Thanh thanh.quang.tran@fokus.fraunhofer.de
> > Envoyé : mercredi 4 février 2015 14:02 À : DANGERVILLE Cyril Objet :
> > Authorize PDP GE
> >
> > Dear Cyril Dangerville,
> > My name is Tran Quang Thanh from TU-Berlin, Germany. I am now working
> > in FI-PPP FI-STAR project.
> > As far as I know, your attribute finder module can integrate with
> > other IdM GE such as GCP.
> > At this point in time, is it possible to use the open source KeyRock
> > IdM GE ? and if yes could you please send us your current
> > configuration with KeyRock.
> > Thank you very much,
> >
> > Bests,
> > Tran
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
Issue Links
- is duplicated by
-
HELP-2095
FIWARE.Request.Tech.Security.AuthorizationPDP.KeyRockIdMAttributeFinder
-
- Closed
-
Activity
Hi Tran,
the addition of metadata for users is not possible in the current implementation of Keyrock. And today we have not immediate plans to add something similar. However, as the new release is based on Openstack Keystone, if you are going to deploy your own instance of the component it is so easy to add a new field in the Users API in order to enable this type of parameters. We can give you some pointers in order to achieve that.
I hope this helps,
BR
–
Álvaro
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
Dear Cyril, Alonso,
Thank you very much for your information.
If I got correctly, upcoming (modified) OpenStack Keystone will provide
such functionality and replace KeyRock IdM at FIWARE Lab.
Will it be another FIWARE IdM GEri ?
Also please give some hints about my first consideration in the last email:
With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?
Bests,
Tran
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
Hi Tran,
no, the new release doesn’t include that functionality. What I mean is that if you are going to use your own instance (not the official one deployed in FILAB), it is so easy for you to implement that functionality.
Anyway we will keep you informed if there are future plans to work on that direction.
BR
–
Álvaro
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
1) By "implement that functionality", you mean "modify/extend the code of KeyRock", don't you?
2) Regarding the second point, do you already know how the mapping from IdM to XACML attributes (in the XACML request) will be configured in the next release of the PEP proxy?
Thank you.
Regards,
Cyril
De : Álvaro Alonso aalonsog@dit.upm.es
Envoyé : mardi 17 février 2015 14:33
À : Tran Quang Thanh
Cc : DANGERVILLE Cyril; fiware-tech-help@lists.fi-ware.org
Objet : Re: [Fiware-tech-help] IdM GE - Adding new attributes (e.g. application-specific)
Hi Tran,
no, the new release doesn't include that functionality. What I mean is that if you are going to use your own instance (not the official one deployed in FILAB), it is so easy for you to implement that functionality.
Anyway we will keep you informed if there are future plans to work on that direction.
BR
–
Álvaro
El 17 Feb 2015, a las 13:53, Tran Quang Thanh <thanh.quang.tran@fokus.fraunhofer.de<thanh.quang.tran@fokus.fraunhofer.de>> escribió:
Dear Cyril, Alonso,
Thank you very much for your information.
If I got correctly, upcoming (modified) OpenStack Keystone will provide such functionality and replace KeyRock IdM at FIWARE Lab.
Will it be another FIWARE IdM GEri ?
Also please give some hints about my first consideration in the last email:
With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?
Bests,
Tran
On 16.02.2015 15:48, Álvaro Alonso wrote:
With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?
Hi, answers inline
Yes.
It will be done in the same way as it is right now. We will include HTTP Verb and Path.
Best
Álvaro
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help
Dear Cyril, all,
Thank you very much for your support and information. I am waiting for
your configuration file
As far as I understand (correct me if I am wrong), in the upcoming
access control model, the connection between Authorized PDP and IdM (the
Attribute Finder) has been removed. This makes the IdM and PDP somehow
more generic and independent, however it might raise a new issue as I
mention in the following:
As you know, in other domains such as our healthcare domain, one of the
reason that we are interested in XACML access control model because of
the flexible capability to create access policies based on many
attributes. Such policies will use not only XACML standard attributes
(e.g. subject-id, resource-id, time etc.) but also our domain-specific
attributes. For example, we have a policy like this:
"Doctor can access medical records of patients from their medical
center. Other doctors can access patient records in case of emergency".
In such policy, we adopt two user domain-specific attributes: care
provider and emergency status
With new architecture, to be sure such attributes can still be extract
from token (if the IdM support) but how the PEP Proxy decide which
attributes to include in the XACML request (do we need to include all
user attributes in the request ?) and when the request contains such
domain-specific attributes, how the PDP understand such attributes in
order to validate the request without communicate with IdM ?
The same concern to the support of domain specific attributes is to the
only FIWARE IdM KeyRock GEri. Does it support a flexible mechanism to
deal with this (e.g. through API or some configuration) ? As far as I
know, the GCP IdM supports such functionality through API that allowing
user create new attributes.
If the GE owner or someone in the list can support, please help us to
clarify this.
Thank you very much,
Bests,
Tran
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fi-ware.org
https://lists.fi-ware.org/listinfo/fiware-tech-help