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.
Related
We are designing a web application and want to use Azure AD External Identities.
We define Multiple clients in our web application, and each client can have multiple users. A client invites users and gives them access to data by their email addresses, which could be personal or organizational.
Users log in to the application. After the login, if they have access to multiple clients (because different clients can invite them), they should be able to switch between clients and get an access token for the selected client.
It is essential to mention that each user has different permission on different clients; for example, a user can have admin permissions in one client and simple user permissions in another.
Is it possible to have these features in Azure AD?
How should We use Group, Scope, and Role to implement it?
Whenever external identity providers (azure ad in this case) are used in 3rd party application:
It's scope which defines permissions. It can be specified at client(application) level. Hence Whatever scope you define for a particular client it would apply to all users. Obviously You can create multiple applications which contains different scope.
roles,groups has nothing to do with generating access tokens since those are used only when you login into azure portal.
Here You will have to use client credentials flow of OAuth 2.0. Otherwise user will need to login each time if auth code flow is used.
I am developing multitenant web application which is being hosted on azure app service.
It has 2 parts one is backend services which has pure APIs developed using .NET CORE and second is front end which consumes these APIs and is developed using Angular.
We are using Single instance , database per tenant concept where each user will have its own Database.
So there will be a catalog Db , which will hold information about each customer's tenant Id, tenant's Database connection string , customer Id etc.
We do not want to use Azure AD as of now, as our APIs are connecting to different ERPs to validate the user and data.
To achieve multitenancy, we are thinking of 2 ways
Unique Secret Id called TenantKey (for which we will be using some hashing function on TenanatId)
So every time they login, they need to enter this TenantKey along with UserId and password , so we authenticate this user based on that TenantKey and fetch DB connection string based on this.
We validate user by connecting to their own DB using Connection string fetched from CatalogDb.
Once we validate, we generate JWT token and this Connection string of Tenant's own Db is stored as Claim and will be used every time when user calls any API using this token.
This is working fine but
user has to remember and enter this TenanatKey along with UserId and password when they login everytime... which may not be user friendly...
As it is multitenant app, If another tenant gets to know the TenantKey they can access the info provided that they know the credentials(rare but possible)
Custom Domains
As Azure provides way to add custom domains to Azure App service through which we can identify the Tenant and Instead of TenatKey, we will be using this custom domain to find the Connection string in Catalog Db, create JWT token and store as Claim and use it
So question is , is there any way to secure these custom domains so only particular customer can access it? Like in their VPN?
I heard there is limit of 500 domains that can be added to an App service? will there be any way to extend if needed?
We will have load balancer going forward, will this customer domain have any effect on that?
Restrict your multi-tenant app to specific tenant
There are two steps to get started with tenant restrictions.
First, make sure that your clients can connect to the right
addresses.
Second, configure your proxy infrastructure.
To use tenant restrictions, your clients must be able to connect to the following Azure AD URLs to authenticate: login.microsoftonline.com, login.microsoft.com, and login.windows.net. Additionally, to access Office 365, your clients must also be able to connect to the fully qualified domain names (FQDNs), URLs, and IP addresses defined in Office 365 URLs and IP address ranges
For information on how to configure the proxy and the above process, refer here.
Output will be like this after configuring:
Restrict your multi-tenant app to specific users
If an app is secured with Azure AD, it's available to all users who authenticate successfully. But we will have the requirements to restrict access to specific users. This can traditionally be done within the application based on the roles.
Tenant admins and developers can restrict an app to a specific set of users or security groups in the tenant by also using this built-in Azure AD functionality.
Step 1
Log in to the Azure portal as a Global Administrator. In the top Azure bar search for the “Azure Active Directory”.
Step 2
From the properties left pane look for the “Enterprise applications” like below,
Step 3
Look for the AD application which you want, if you don’t find your application then select “All Applications” from the Application Type dropdown and use other filters also to find the application.
Step 4
Once you select the application, select “Properties” in the left menu and enable the “User assignment required” option to “Yes” and “Save” to update this configuration change.
Step 5
Make user assignments: Select “Users and groups” > Click “Add user”.
Step 6
It will direct you to the next page, where you may choose which users have access to the app services made available through this particular Azure AD app authentication.
Now, the user will be successfully authenticated when they attempt to log in to your Azure App Service with any legitimate AD user, but they will only be able to approve the application based on the configurations we just made.
For more information, refer here in Microsoft documentations.
I heard there is limit of 500 domains that can be added to an App service? will there be any way to extend if needed?
Yes, What you heard is correct!
You could try to contact Azure support to increase the limit:
Navigate to your subscription in the Azure Portal
Click on Usage + Quota
Click on Request increase
Select Other Request in the Quota Type field
Fill all other fields of the request
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.
We are currently building a web app using a full serverless stack on AWS. So far we have been very successful using AWS Lambda, AWS DynamoDB and Cognito User Pools. This application is intended to be an enterprise application and one of my clients wants to be able to log all users in using their current Active Directory credentials. I have used AD FS in the past on other applications but it has always turned out to be a bit of a hack to get it working.
Now, I want to send the customer instructions on how to configure their AD FS relying party trust to authenticate against my application.
I have read that the best way to do this is to create a Cognito Identity Provider that links to a Cognito User Pool. In the User Pool you should create a SAML provider and upload the metadata.xml from the AD FS server.
I have set up a lab server with AD FS and I can get that working. Now I am not sure what I am doing wrong in terms of the Relying Party Trust setup or the Cognito setup. I have been at this for ages and read just about every blog article I can find. If anyone can help me out or point me in the right direction that would be greatly appreciated.
After much frustration, I can now answer this question so I decided to put together an easy step-by-step answer for beginners with these struggles.
I am only going into the authentication setup and not the authorisation. Authorisation requires IAM roles and some other logic that is architecture specific. I'm happy to discuss that elsewhere.
There are 2 components to this kind of a setup:
An AWS Cognito user pool with a federated identity provider
Windows Server with AD FS installed
Creating the Cognito User Pool domain
In the Cognito User Pool under General Settings, select App clients and add one if there are none (you will need the ID later).
Then go to Domain Name under App Integration and choose a valid domain prefix and save it.
Relying Party Trust in Windows AD FS
You will need to get the company to setup a relying party trust. The steps required are as follows:
Open the AD FS management console
Create a new relying party trust
Select to enter the details manually
Enter a name for the trust that is easily identifiable as your application
Select to use ADFS 2.0
In this example, there is no need for a certificate so just click next
Select the checkbox to enable the SAML 2.0 protocol and enter the URL in this format: https://<domain_prefix>.auth.<region>.amazoncognito.com/saml2/idpresponse (domain prefix is set in the previous step)
The relying party trust identifier needs to be urn:amazon:cognito:sp:<pool-id> where pool-id is the AWS Cognito User Pool id found in the General Settings of the user pool
Permit all users to authenticate (assuming that is your intention)
Now you need to add claims to the relying party trust.
Right-click on the relying party trust and click edit claims
Create a new claim that sends LDAP attributes
Give it a name (I normally use Profile but this is up to you)
Make the attribute store Active Directory
Fill in the table as you need. A requirement is that you have a Name ID being returned (I normally use the User-Principal-Name mapping to Name ID). The rest of the table is as you need. For example, Given-Name can map to FName
Federated Identities in AWS Cognito User pool
So as the application developer, you need to setup the Cognito User pool. Go through the wizard and choose your prefered settings. The federated identities don't necessarily play by the same rules as the user pool itself anyway.
The steps to setup the federated identity are:
In the Cognito user pool select Identity Providers under Federation
Click on SAML
Provide the metadata document endpoint (normally in the form of https://<fqdn>/FederationMetadata/2007-06/FederationMetadata.xml). If you can't then download that file and upload it by clicking "Select File"
Enter a provider name that makes sense to you but make sure not to put any spaces in the name
The identifiers are optional (see below for their use)
Checking enable IdP sign out flow will sign your users out of their federated identity as well as your application on sign out.
Click create provider
Attribute Mapping for Federated Identity
Create the field mappings for the Federated Identity by going to Attribute Mapping under Federation in the user pool.
Select SAML
Click Add SAML Attribute
Make sure Capture is checked, enter the SAML attrbites from above (such as FName) and select the user pool attribute that it maps to.
Setting up the App Client
The last step before testing is to setup the app client that you created earlier.
Go to App Client Settings under App Integration
Enter the settings for the appropriate app client
Select all the appropriate identity providers (specifically the one setup above)
You can set a comma-separated list of callback and logout URLs. The callback URLs should point to somewhere that will use the token after authentication (see testing below).
Select the OAuth 2.0 attributes as required but for testing select everything but Client credentials
Testing
To test, you can try a few different URLs in the form of: -
https://<domain_prefix>.auth.<region>.amazoncognito.com/authorize?idp_identifier=<idp_identifier>&response_type=token&client_id=<app_client_id>&redirect_uri=<app_client_callback_URL> to go directly to the authorize endpoint
https://<domain_prefix>.auth.<region>.amazoncognito.com/login?response_type=token&client_id=<app_client_id>&redirect_uri=<app_client_callback_URL> to go to the AWS hosted login UI
The idp_identifier is the optional field defined when creating the federated identity. This is not required in the URL either.
This one page webapp is a good tool to use to test that things are working and you are getting the desired response.
I hope this helps other people.
I have an Azure SQL Server with two databases for which I'm trying to use Azure Active Directory Integrated Authentication. One of these databases is critical and most of the users need to be granted only 'read' access for this database.
To add a new user with a 'Reader Role', I did the following:
Added the user with Reader role under Access Control(IAM) from the Azure portal.
The user wasn't able to connect after this step.
Then I tried adding the user using the following commands:
CREATE USER [name#domain.com] FROM EXTERNAL PROVIDER;
sp_addrolemember db_datareader, [name#domain.com];
The user is still not able to connect to the server using AAD Integrated Authentication. In both the cases I get an Anonymous Logon error.
Click to see the snip of the error message
Am I missing something? If not, is there any other way I can add users with specific permissions to the database?
Sorry for the delay, M.
Yeah, you've confused two different levels of access control; the IAM controls that you described (Reader role assignment) allows a user to view (read) the settings in the Azure Portal. Instead, I suspect you want a user (AAD authenticated) to be able to only read the data on the server. That's done via T-SQL and has nothing to do with the Access Control defined by the portal.
Now, you're attempting to create an external user (AAD access) on the database level, and you want them to have read permissions- make sure you've covered all the steps outlined here.
At a glance, the following may be necessary steps:
1.) Ensure that you've assigned an AAD admin for the SQL Server.
2.) Ensure that you're connecting to the database you want to create the users on, not the master db as you ordinarily would on a non-azure SQL Server instance. Create the user via T-SQL using the following:
CREATE USER <Azure_AD_principal_name> FROM EXTERNAL PROVIDER;
3.) Grant the user db_datareader permissions on that database:
ALTER ROLE db_datareader ADD MEMBER <Azure_AD_principal_name>
GO