As part of the FINISH accelerator we are using FIWARE KeyRock and Wirecloud. Currently we are using the Fiware labs global instance to investigate.
We want to restrict our system so that users can only view data that belongs to the organisations of which they are a member.
The following flow seems logical, but correct me if i am wrong:
A user logs into Wirecloud and is directed through a KeyRock login screen.
A Wirecloud Widget gets an access token from Wirecloud environment. The access token was created when the user logged in.
The Wirecloud widget looks up the organisations and roles that a user is member of. Based on this it adds organisation names to its query.
The Wirecloud widget queries a webservice (Orion or otherwise) using the query it just created.
We put the Wilma PEP proxy between the Wirecloud Widget and the webservice to validate that the user is a member of the organisations in the query.
PROBLEM:
We can query user information from KeyRock using the https://account.lab.fiware.org/user?access_token=XXXXXXXXXXX call. But that does not contain any information about the organisations that the user is a member of according to the KeyRock web interface. The organisations element is an empty array. We get a bunch of roles in the json response, but none of them is the "members" role that you assign to users from the "Manage your organization members" screen in KeyRock.
Some digging revealed that the Keystone instance running on Fiware labs contains the information (assuming that a Keystone project = KeyRock organisation). However the access token provided by KeyRock is somehow not valid on the Keystone API. The API we used was accessible here: http://cloud.lab.fiware.org:4730/v3/
Getting a new access token from the Keystone API is not what we want, because that would be a different access token than Wirecloud has obtained, which would require some kind of proxy to log in again and retrieve the organisation membership. That rather defeats the point of passing an access token.
This seems to be a bug in the KeyRock API on the fiware labs instance.
Or am i missing something here?
Or will this problem magically go away if we install keyrock on our own server?
Thanks for any help,
Robin
you have to follow the steps explained here but using the specific organization. Probably you have missed the "Authorize" step
Related
I like to have User-A can contribute to the API-A but doesn't have access to the API-B.
When I look at the Azure APIM Built-in roles (link below) I am noticing that the API Management Service Contributor role is defined for all APIs.
Is it possible to to define a "Service Contributor" role per API as opposed with all APIS?
If not, is there any other technique that help me to achieve the same goal
AFAIK, you can restrict the user to specific set of APIs.
1) Through Product Level where you can add the APIs and allow all APIS to the specific set of users by keeping the Scope level to Product for the users.
Created 2 different APIs in APIM Instance like the below:
Open the New APIM Developer Portal after adding the APIs and publish the APIM instance > Portal Overview under Developer Portal.
In APIM Instance > Products > Added new product "Dotnet6FunctionAPIs" - Added the Net 6 Function App APIs > Checked the options "Requires Subscription", "Requires approval" and then published the product.
4. In APIM Instance > Users - created a user and in Products > Dotnet6FunctionAPIs Product > Access control > Allowed the access to Developers group.
Login to the developer portal with the new user login credentials https://<apiminstance_name>.portal.azure-api.net/ > Products > Dotnet6FunctionAPIs product > Click on Subscribe.
Here the Admin can approve the access of that product APIs to the user and can cancel the subscription whenever admin wants to.
After Subscription approval, the user can test the API present in the product.
If you observe here, I have allowed the users (under Developer group) to the product "Dotnet6FunctionAPIs" that contains specific APIs added to it.
This is one of the ways to restrict users from not accessing the other APIs by adding only specific APIs to the product and giving that product access to the users.
Updated Answer:
As Markus told, there are 3 built-in roles in APIM. API Management Service Contributor is for CRUD access to Complete APIM Instance (all APIS & Operations) and cannot be restricted to specific APIs.
I have seen the permissions given to API Management Service Contributor built-in role. Among those permissions, I believe we need to modify at API Policy Level which is
Write (Access) - Set API policy configuration (Permissions) - Creates or updates policy configuration for the API.
I have three service accounts:
App engine default service account
Datastore service account
Alert Center API service account
My cloud functions uses Firestore in datastore mode for book keeping and invokes Alert Center API.
One can assign only one service account while deploying cloud functions.
Is there way similar to AWS where one can create multiple inline policies and assign it to default service account.
P.S. I tried creating custom service account but datastore roles are not supported. Also I do not want to store credentials in environment variables or upload credentials file with source code.
You're looking at service accounts a bit backwards.
Granted, I see how the naming can lead you in this direction. "Service" in this case doesn't refer to the service being offered, but rather to the non-human entities (i.e. apps, machines, etc - called services in this case) trying to access that offered service. From Understanding service accounts:
A service account is a special type of Google account that belongs to
your application or a virtual machine (VM), instead of to an
individual end user. Your application assumes the identity of the
service account to call Google APIs, so that the users aren't
directly involved.
So you shouldn't be looking at service accounts from the offered service perspective - i.e. Datastore or Alert Center API, but rather from their "users" perspective - your CF in this case.
That single service account assigned to a particular CF is simply identifying that CF (as opposed to some other CF, app, machine, user, etc) when accessing a certain service.
If you want that CF to be able to access a certain Google service you need to give that CF's service account the proper role(s) and/or permissions to do that.
For accessing the Datastore you'd be looking at these Permissions and Roles. If the datastore that your CFs need to access is in the same GCP project the default CF service account - which is the same as the GAE app's one from that project - already has access to the Datastore (of course, if you're OK with using the default service account).
I didn't use the Alert Center API, but apparently it uses OAuth 2.0, so you probably should go through Service accounts.
I am trying to get the policies for all the resources so I can view the roles and members associated with them. Any method of getting all the policies through the API would work for me.
I am currently trying to list the organizations (resources) so that I can then get the policies for each resource with a command like GetIamPolicy. However, the organizations.list command returns null. Let me know if any of you have had success getting any policy.
I am using the C# API with a service key to connect to my Google Cloud account.
If I understand correctly, you're trying to get the list of all of your GCP Organization resources so that you can cycle through the list to get the IAM policy bindings for each organization.
Get organizations from Cloud Resource Manager API:
To accomplish this, you would first use organizations.search (with no filter) to get a list of all of your organizations.
Try it here with the API Explorer.
Get organization IAM policy from the Cloud Resource Manager API.
Then, for each organization, you would use the organization name to call organizations.getIamPolicy in order to get the IAM Policy for that organization.
Try it here with the API Explorer (update the resource to reflect your organization name).
Note: IAM Policy is how you control access to resources in GCP. There are various levels at which you can manage IAM Policies, including organizations, folders and projects. There is a entirely separate concept called Org Policy, which allows you to control which API services can be enabled in each of your projects.
I have multi-tenant application, which exposes some API for our customers to use. I would like to expose it using Azure API Management. Mostly to provide Development Portal to our customers, which I find very useful, and maybe use some other features.
If I understand correctly, our customers will set up their own subscription keys for authentication, which API Management proxy will validate.
Question: How can I link and identify user/subscription to the tenant of my application, to ensure that only data from this tenant are returned.
One direction I can see to explore is to use delegated sign up, which I guess will help me to link subscription to the tenant. But then still the question is how to get user id in my backend API?
Any direction to documentation or samples is very appreciated
You could create separate groups in APIM to represent your tenants and then put users into those groups using delegation hookups. Withing APIM policy in expressions you can reference context.User.Groups to list groups user making the call belongs to and forward that information to backend.
Alternatively you could use Note field to store tenant name and access it as context.User.Note. Or if you're willing to store mapping on your side the just take an id context.User.Id.
All of above could be passed as a header using set-header policy like:
<set-header name="userId">
<value>#(context.User.Id)</value>
</set-user>
All scenarios would require you to have delegation setup to fill this information automatically for every new user created.
In the global Wirecloud instance i have a widget which uses the KeystoneAPI mentioned here:
https://wirecloud.readthedocs.io/en/stable/development/object_storage_api/
So far so good.
However now i want to move to KeyRock for authentication. I still want to pass tokens from my wirecloud widget to backend services like the Wilma PEP proxy which is not connected to KeyRock as well. But the KeystoneAPI seems to be tied to Keystone (hence the name probably).
Is there a KeyRockAPI accessible from Wirecloud widgets? How can a widget obtain the KeyRock OAuth2 token the user logged in with? I cannot find any documentation on this.
WireCloud doesn't allow widgets and operators to read the OAuth2 token assigned to the user, but it provide support for injecting the token into HTTP requests if they go through the WireCloud's proxy. This injection is controlled by several HTTP headers, this is an example:
MashupPlatform.http.makeRequest(url, {
requestHeaders: {
"X-FI-WARE-OAuth-Token": "true",
"X-FI-WARE-OAuth-Header-Name": "X-Auth-Token"
},
...
});
You can find more info about how to use this feature in the FIWARE Academy course, more specifically in the 3.1.8. Accessing third-party services using IdM tokens section (take into account that this document is the same you pointed in your comments, but in html format ;) ).
Answers to the others questions formulated as comments:
Installed docker containers of KeyRock and Wirecloud, tried out the objectstorage demo widget, which failed to retrieve an authentication token. Traced the problem to %idm_token% not being filled in by the python code, presumably in plugins.py because it looks for an AUTHENTICATION_BACKEND of 'fiware' whereas the documentation states to include 'wirecloud.fiware.social_auth_backend.FIWAREOAuth2'.
I recommend you to create a new question in StackOverflow to tackle this problem. Please, provide more details on your configuration.
So my authentication token from wirecloud will be bound to that application? If so, the token is useless to my own application unless i can get a new token for it. Am i wrong here?
Yeah, the Mashup portal is the application number 17 in the Account portal and the OAuth2 token obtained by WireCloud is bound to that application. I cannot foresee if that token is useful for your application or not. This token can be used for authenticating users, but the IdM limits the returned information (e.g. roles) depending on the application bounded to the token. So, evidently, this integration is not perfect, but we are missing some integration features from the IdM to make it more useful.