I've currently working with ObjectStorageGE and I am able to publish and edit my objects inside the Object Storage using CDMI. For tracking pourposes I want to browse in FiwareLab -> Cloud -> Containers the objects that users of the organization has published. However, I cannot access to containers published to Organization tenant (or I cannot find to way to do it...) using the Organization owner account.
PS: I can browse containers and objects correctly in FiwareLab if I publish them using my own user tenant.
From FIWARE help-desk:
"I don’t understand why you talk about “Organisation tenant” on one side and about “my own user tenant” on the other side. What do you mean with those different tenants? Are you using the same tenant in both sites (cloud portal and API)?Take into account that only some tenants are visible in the cloud portal (the default cloud tenant associated to a user)"
In general, in order to access containers, the user must belong the tenant (account) that owns that container. This is to impose separation of access between tenants. In recent versions of Swift Object Storage there are mechanisms to allow access to others, but these are not enabled in the versions running in the Fiware lab.
Related
I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.
Is it possible to have logical separation of Azure APIM service i.e one could work like Prod and Non-Prod at the same time?
If you check this Azure API Management DevOps Resource you would find that Microsoft recommends to use separate Azure API Management service instances for various environments, such as production, development, and QA. Where these environments are generally shared by multiple development teams, each responsible for a subset of APIs. It is the best practice for the enterprise setup.
But if you don't want to create multiple instances then, you could try using versions and revisions.
You can create revisions by right clicking API and click "Add Revision".
Similarly you can create versions by right clicking API and click "Add Version".
For more information check this answer by #DSpirit on the similar problem shared in Stack Overflow.
Scenario: Externally exposed API, connects to multiple backed Dbs. Multiple customers can use the API, they obviously should only have access to their data. In the past this is done by separate accounts for each customer/user, and consequently each account would need setting up in each of the backend systems with the correct authorities.
Problem: I want to use Azure APIM. I don't want the extra maintenance for each user in both the Azure APIM and the backend Dbs. I was wondering if anyone has any thoughts or cases where they accomplished this in a different way. Also the API may be built with access via one account with all access to tables.
I'm sure there are different ways to approach this but a common way I believe to do this would be using Application Roles.
I don't believe this is really dependent on Azure APIM as such, but you can leverage OAuth 2.0 support to pre-authorize requests and in your backend, depending on the claims present in the token passed, you can allow/deny access to the data.
You backend would usually authenticate to the different DBs as itself with full access to all data and your backend would be tasked with making sure only people with the right claims can access the data.
In order to use an API the user/customer has to register with the Developer Portal and get a Subscription to a given API and the associated key. So you have to authenticate them. When you publish APIs through Azure API Management, it's easy and common to secure access to those APIs by using subscription keys. Client applications that need to consume the published APIs must include a valid subscription key in HTTP requests when they make calls to those APIs. https://learn.microsoft.com/en-us/azure/api-management/api-management-subscriptions
The Developer Portal supports different authentication mechanisms including Azure AD. So if you plan to use Azure AD for your authentication for both portals you will need to configure it accordingly. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad
we have a common APIM setup where developer publishes and subscribes products. Can we restrict certain developers to only publish APIs under specific product. We don't want a developer tampering with the product published by another developer. I found a document where we can restrict the visibility from a subscribers perspective link to doc
Can a similar access control can be done for a publishers?
Look into ARM custom roles: https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles You should be able to create RBAC rules for your developers scoping access only to a certain products, since API membership in product is controlled by /products/{pid}/apis/{aid}
There is a concept called "groups" provided by azure, which will help us to group users and give privileges based on the roles(RBAC). Groups are further divided into two types
1.Default
2.Custom
A specific group of users can be given permissions edit to a specific product and only read some other product.
For Further reference follow the link: https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-create-groups
Is it possible to make an integration between Alfresco and LDAP to manage groups, users and permissions?
I mean, alfresco groups must be managed with its own set of permissions? Currently I have a LDAP repository to allow authentication, but it is a lot of work to maintain users and groups across multiple systems.
In other words, can i make a full integration between these two environments easily and without modifying the core of alfresco?
Thanks in advance
Short answer is no.
IMHO, externally managed users, groups and authentication are already the maximum to make sense of. Even then, a part of authorities (users / groups) will still be created locally in alfreco when you start using share sites and invite external people. Sure, this could technically be changed, but alfresco writing to LDAP opens a new can of worms. The default LDAP read/sync approach should not cause sigificant extra efforts.
Authorization data, such als roles (which can easily be confused with groups) and permissions and their semantics are highly dependent on application (alfresco). It does not make sense to manage them in an external system that has no clue.