I'm trying to make a mashup public. This mashup uses Orion Context Broker to draw some PoI in a map. I've looked at documentation on github and tried changing port to 10026 and disabling the use of credentials, but I don't get any PoIs this way.
The NGSI Source Operator settings are:
NGSI server URL: http://orion.lab.fiware.org:10026/
NGSI proxy URL: https://ngsiproxy.lab.fiware.org
Use the FIWARE credentials of the user : disabled
Is there any way to achieve this?
As stated in the NGSI source operator documentation (version 3.0.3), using the 10026 port was a hack for supporting public workspaces. That hack doesn't work anymore.
Version 3.0.4 of the NGSI Source operator adds support for using the credentials of the workspace owner instead of using the credentials of the logged user (through a new preference: Use the FIWARE credentials of the workspace owner). This can be used for creating a workspace and make it public.
Related
We have a requirement where we need to have multiple versions of the same API with few changes in it, but we cannot change the URI whatsoever.
URI versioning : api.example.com/v1/resource
Domain versioning : apiv1.example.com/resource
(Request) parameter versioning: GET /something/?version=0.1 HTTP/1.1
In these example, we might have to change or add version numbers in the URI.
Is there anyway through openshift to do API versioning and not change the URL.?
You'd have to look at Red Hat's API Management solutions.
If you are on OpenShift Dedicated, there are some bundled entitlements of the hosted Red Hat OpenShift API Management. If you are on self-managed OpenShift, you'd want to look at 3Scale API Management. Essentially the same product/features, just managed vs. not.
I'm doing some tests with Azure APIM and have already published an API on the developer portal. I have the docs, have it secured using OAuth2 with Azure AD with client_credentials flow. I can invoke this API from Postman and from the developer portal.
Unfortunatelly, the client_id and secret are set on the configuration and the developer cannot self service them. Is there a way to do so instead of having to add it manually to each developer?
I was looking for something like this: https://tyk.io/docs/tyk-stack/tyk-developer-portal/portal-oauth-clients/
Azure APIM itself doesn't act as an identity provider like tyk but instead uses Azure AD (or rather any OAuth 2.0 provider).
The configuration in the docs is primarily to get the Developer Portal Console (the one used to test APIs) to work. For the actual API calls, there is no configuration required.
The validate-jwt policy is what takes care of preauthorization of requests.
Since you are looking for the client credentials flow alone, you could simply expose a portal that can create the required app registrations on your Azure AD using the Microsoft Graph API and expose the client id/secret to your users.
The current developer portal doesn't support this as of today but is something you could contribute to if you wish.
First of all, I'm using the Telefonica implementations of Identity Manager, Authorization PDP and PEP Proxy, instead of the Fiware reference implementations which are Keyrock, AuthZForce and Wilma PEP Proxy. The source code and reference documentation of each component can be found in the following GitHub repos:
Telefonica keystone-spassword:
GitHub /telefonicaid/fiware-keystone-spassword
Telefonica keypass:
GitHub /telefonicaid/fiware-keypass
Telefonica PEP-Proxy:
GitHub /telefonicaid/fiware-pep-steelskin
Besides, I'm working with my own in-house installation of the components, NO Fi-Lab. In addition to security components, I've an IoT Agent-UL instance and an Orion Context Broker instance.
Starting from that configuration, I've created a domain in keystone (Fiware-Service) and a project inside the domain (Fiware-ServicePath). Then I've one device connected to the platform, sendding data to the IoT Agent behind the PEP Proxy. The whole device message is represented as a single Entity in Orion Context Broker.
So, the question is:
How can I restrict a specific keystone user to access only to the entity associated to this device, at the level of the Orion Context Broker API?
I know that I can allow/deny user acces to specific API via keystone Roles and XACML Policies but that implies that I should create one Policy per User-Device pair.
I could use some help with this, to know if I'm on the right way.
I do not think Access Control can be done to Orion without Security GEs. Each GE has a specific purpose and access control is not one of the Orion's purposes.
As stated in the Security Considerations from Orion documentation:
Orion doesn't provide "native" authentication nor any authorization mechanisms to enforce access control. However, authentication/authorization can be achieved the access control framework provided by FIWARE GEs.
Also, there is something related in another link:
Orion itself has no security. It’s designed to be run behind a proxy server which provides security and access control. Used within the FIWARE Lab, they run another service build on node.js, “PEP Proxy Wilma”, in front of it. Wilma checks that you have obtained a token from the FIWARE lab and put it in the headers.
Besides, the link below can endorse my opinion about Orion and access control:
Fiware-Orion: Access control on a per subscription basis
My opinion is that you are in the right way using the other security components.
About "create one Policy per User-Device pair" as you mention, maybe it would be better you thought about "group policies" instead.
We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to
create a user
add that user to an organisation
authorise the user for an application
We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
When a new user signs up:
a 'cloud organisation' is created.
By default, the 'provider' and 'purchaser' roles are present
and the 'Store' application is assigned to the user (although i cannot verify this).
We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.
However this does not make any sense for our local installation.
How can we prevent Horizon from creating the cloud organisation upon user sign-up?
How can we assign a default application authorization upon user sign-up?
-- Edit --
It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.
All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:
Wilma PEP Proxy GE
Wirecloud Application Mashup GE
Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases.
If we decide to use Keystone instead, we will lose
OAuth2 support
Permissions
sign-up, admin and login screens.
Is anyone else having this problem?
How have they tackled it?
-- SCIM API --
Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'
I'm using the API Gateway service to manage my spring boot resources. I want to point the gateway to my sub-domain. I tried adding it to alias in Route 53 but it does not work. There's an option in the API Gateway console which asks for my domain and some credentials. I don't know if a sub-domain can work and what should i add to certificate input. Probably it is asking for an SSL certificate and I am ready to purchase one, but before i do that, i want to be sure that it accepts sub-domains.
Yes, API Gateway supports subdomains. You can try with self-signed certificate and see the options.
See the official documentation on using Custom Domain Names in API Gateway.