I am trying to create a new user for an application which uses CosmosDB. From the documentation, it expose a service method to create a new user.
I believe the created user can access the Cosmos DB provided the users are updated with certain permission to the collections
And my query,
Is there a service method to create a user with password? If not, any alternatives to do the same?
Is there a way to see the created users in Data Explorer rather than List Users?
1.Is there a service method to create a user with password? If not, any alternatives to do the same?
As I know, no such method in cosmos db. Based on this document, Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources. User and permission is resource token type here. It's meant to avoid the risk of master key exposure. It is authenticated by token,can't be password.
If do want to use password for authentication, maybe you just have to protect the token by password with your own logical code. Other words, you get the above resource token first then manage the mapping relationships between user and resource token by yourself.
2.Is there a way to see the created users in Data Explorer rather than List Users?
It can't be found on the portal now.You need to list users and permissions using sdk or rest api. You could commit feedback here to ask azure cosmos team to add this feature.
Related
We are trying to figure out a way to synchronize users from Azure Account into the Keycloak?
Unfortunately, we could not find a documentation for it
Do you know a proper way to do it ?
I want to use Azure as an external DB that I can use to authenticate my users.
Thank you
I want to use Azure as an external DB that I can use to authenticate
my users
For that you can use Keycloak's User Federation functionality:
Many companies have existing user databases that hold information
about users and their passwords or other credentials. In many cases,
it is just not possible to migrate off of those existing stores to a
pure Keycloak deployment. Keycloak can federate existing external user
databases. By default, we support LDAP and Active Directory, but you
can also code your own extension for any custom user database using
our User Storage SPI.
The way it works is that when a user logs in, Keycloak will look into
its own internal user store to find the user. If it cannot find it
there, it will iterate over every User Storage provider you have
configured for the realm until it finds a match. Data from the
external store is mapped into a common user model that is consumed by
the Keycloak runtime. (..)
In that section of the documentation you have all that you need. Nonetheless, to add the User Federation:
Go to your Realm;
Select User Federation;
Add provider -> ldap;
Configure all the Required Settings accordingly;
Save.
On Azure cosmos DB, I want to have a user with access only to DATA plane (no CONTROL plane).
Following the REST API (https://learn.microsoft.com/en-us/rest/api/cosmos-db/create-a-user) I am able to create a user then to grant him permissions.
Now, I'm stuck with control of the Token.
I can get it automatically when setting the permissions. But no more.
Besides, why should it be included in the connection string
Getting a permit, enables me to get the Token for example
"_token": "type=resource&ver=1&sig=/l3kOULV1Vjk+ZnBqUmzow==;dkMrrNO/x8YperU6omZmUmNcwPCXPmpWUFtB3HFFNlqxvGCJsx0tk2IjOPVYf/jV53fAxaBq9vrB7eXG5dgGAJWCTzm1A0L1Hi5FMeo5uxrDn3be3ySifJxKe0uby6eAQ4XrQUKHwGz14y9fkBxuHt8GoZlFEWo5hZHyuSv/hOvvxeM7N4BBIbEiToGiZjt+g6Gx5qvipGMd16X//EpvWs8EXHMUBqf4x0KR4WODiBs=;"
Tokens are only valid for an hour but you can override this and extend for up to five hours. Permissions
If you will be using resource tokens to manage access to Cosmos you will need to implement a token broker to manage this. There are two examples I can point you to.
Token broker for a Xamarin mobile app
Token broker created by Citrix in Java
Hope this is helpful.
I'm transforming a legacy system that stores its users in a database (including credentials) to use Azure AD B2C for authentication.
My first step is to rewrite the frontal API (the API that serves the web client directly)
Because many other systems and database tables depend on the users table and its columns, I've decided on creating a db user for every new azure ad registration.
This is the problem, the user id in the database is the primary key, an auto incremented number.
The id that I extract from the access token claims is a ad object identifier, a GUID.
To be able to relate an ad b2c user entity to a database user entity, I will have to create a new column in the users table, AzureObjectId.
The problem is that now I would have to constantly do the conversion between AzureObjectId which I extract from the access token, to the database users id, because other database tables and other internal APIs that I access expect a database user id.
What would be the right way to tackle this?
What I can thinks of is
Transforming AzureObjectId to database user id during every interaction with the database or another internal API.
Once my API creates the database user, use the Azure AD B2C Graph API to add a new claim, database user id, to the user.
Both of these I want to avoid.
Is there someway to enrich the access token with the database user id?
I would go with second option as its a one time operation and system doesn't need to do the conversion every time.
Update with details
This seems to be a migration scenario as well. Check samples here
You will also need to use Restful api feature of custom policies as well.
During the signup process, execute a restful technical profile which will call an api in contoso (your) service to create user. The contoso service will return the database user id of the newly created user. This new userId can be used as a subsequent claim for the user and AzureADB2C will create the user with that extension property.
The another approach is what we discussed earlier. After signup the user can be created by the service and for the first call, service can insert a claim for itself with new database user Id.
Yes - use custom attributes
You can add custom attributes via the portal and select these to return them as claims in the token.
The Graph API link above shows how to create them programmatically.
So if you populate the database user id into the custom attribute you'll be able to return it in the token.
Settings
I'm creating an Azure Logic Apps (which is one of the recommended tool from Microsoft for integration purposes) to fetch all "work items" and "projects" from Azure DevOps.
As I said, it is to integrate with other data sources in a Cosmos DB database.
I already integrated some of our internal cloud hosted software to the Cosmos database and I therefore have a working workflow which is, querying -> parsing -> formating -> publishing.
Issue and question
I would like to use the best authentication method so that it is not linked to a single user, but more on the organization level. (If the "admin" employees leaves the company, I wouldn't want to have to regenerate a new token with the credentials of the new admin, etc)
I would like to know which are the best avenues for this kind of project.
Would associating the fictive Azure AD admin to the DevOps admin rights and using his account with an API Connection to DevOps be a good idea?
It seems messy to me and I was hoping something else would work.
The results to the queries would be integrated with other data sources from our other internal softwares to do BI reporting. As a mater of facts, all our other cloud hosted softwares had REST API in which you could create a permanent token not associated with a user, but instead with our license, and had all read-write rights. Why is this not a thing with DevOps?
Things that did not work for me
I have already tried generating a token with my own account. I also asked our admin to generate a private access token, but they have expiry date and this is a problem to have our integration set-up.
I have also looked in this documentation, but all the methods seem to use user-related authentication, no full-scale, or organization-scale authentication.
Expected Workflow
This is the desired workflow
Like you've already researched, I believe authentication is always in the context of a user.
The only solution I see is to create a new user in AAD which you control and use a token for that user in your Logic App.
Will the Azure AD UserInfo.UniqueId property always have the same value coming out of the Azure AD instance?
Once a user is Authenticated via Azure what can I use to fetch the roles and privs from our side (we have an existing structure). Since we don't have a password, I was thinking that we could store the Unique Id of the Azure AD User and look up the roles and privs that way....thoughts?
The UniqueId is sourced from the "best" identifier we receive from the service. In the most common case today that is the ObjectId of the user - which can indeed be used for retrieving more info. Please refer to https://msdn.microsoft.com/en-us/Library/Azure/Ad/Graph/api/api-catalog for more info on the queries you can perform.