I am trying to build a multi tenant SaaS application with HapiJS and MongoDB. I would like to achieve the following:
Each tenant has a unique URL
I would determine a tenant from the URL
Same code base for all tenants launched with different configuration, and each tenant runs on different node process
Each tenant has separate database
Is there a reference example/application I can use for direction?
Related
I want to config Keycloak to work across multi-tenancy / realms, so how to config client to work across multi-realms?
If you have a client application that is multi-tenant aware and every tenant is mapped to a different realm, different clients within a single realm, or a combination of both, you may want to implement a KeycloakConfigResolver in your client application and keep sepearate configs per client.
Assuming you are using Java and OIDC, check out the adpater documentation for multi-tenent support.
I have a springboot application linked to a postgresql database. The app is secured using keycloak (keycloak springboot adapter). The idea is to have multiple schemas in the postgres database for different groups of users that login. I hope to identify the user-group using the keycloak token that is received by rest endpoints on the springboot server and then access the respective schema.
Where should I start ? Can anyone point me to a guide for this ? or is there any other better approach ? Any help would be appreciated.
edit ::
Let me try narrowing it down a bit. Lets say the db has the schemas : public, tenant1, tenant2, tenant3. In the keycloak server, I have two clients in the same realm, one for spring boot app and one for my website. I have 3 groups. group 1 has users A and B, group 2 has users C and D, group 3 has users E and F. If the user A logs into the website, he has a keycloak token that is going to help him get the data through ajax requests from the springboot server. I assume that, the incoming ajax request could provide the kc token which would tell spring boot that user A is requesting the data and he belongs to group 1. Here, I want the spring boot server to figure out that the data has to be fetched from the schema "tenant1" and do accordingly. Similarly, group 2 should be directed to tenant2 and group 3 to tenant 3. I want support on the part where the spring boot has to figure out the user and the group and access the right schema..
Cheers,
Vikram
I have a requirement to enable multi tenant support for a spring boot application, it uses mongodb ,requirement is to use separate database based on tenant login.
Each request of REST service call will have the tenant information in header.Based on the tenant retrieved from service request, application should connect to corresponding database.
Azure Active Directory has the nice concept of applications and service principals to authenticate as an application e. g. for a CI platform or SaaS application.
Now there are multiple ways to create those like using MSOL with the cmdlet:
New-MsolServicePrincipal -DisplayName "My new API app" -Type password -Value $myClientSecret
This works perfectly fine (after I assign some roles to the service principal using Add-MsolRoleMember, I can access the Graph API). But I still have some questions:
Why does this cmdlet doesn't require to create the application first?
Does this cmdlet create both - an application and a service principal?
Why I don't see the application neither in the classic nor the new azure portal?
And maybe someone can answer me a fourth question: What is the difference between the above MSOL cmdlets and New-AzureRmADApplication + New-AzureRmADServicePrincipal cmdlet? When should I use which of them?
The ARM cmdlets and the new Azure AD v2 cmdlets both use the Azure AD Graph API.
However, New-MsolServicePrincipal does not. It calls out to https://provisioningapi.microsoftonline.com/provisioningwebservice.svc using SOAP. It is a legacy API and you should not be using it.
A service principal must always have an appId, that is the client id of the Application from which it was created.
The field appOwnerTenantId identifies from what tenant the app came from. It can be null. This is the case for MS internal applications like the Graph API, Azure Portals etc. But also service principals created with New-MsolServicePrincipal, and leaving out the appId.
So the answer to question 1 and 2 is: an Application is automatically created if none is specified. But I am not sure where it is created, as it is not available through the Graph API. It is a pure service identity. And the appId is different each time, so it is not just using some placeholder app.
As for question 3: the reason you don't see the Application in the portal is because it is not available through the Graph API, it is hidden somewhere. As for the Service Principal, a very specific magic tag is required for the principal to show up in the Enterprise Applications list. And AFAIK, you can't specify it with New-MsolServicePrincipal or New-AzureRmADServicePrincipal.
The answer to your fourth question is that the MSOL cmdlets use a legacy API, whereas the two newer options use the Azure AD Graph API. And the ARM cmdlets create an application that you can see in the Portal. They still create one you can't see in the Enterprise Applications list.
The behaviour of the different cmdlets differs when it comes to creating service principals without an app though:
New-MsolServicePrincipal: Creates the principal with some kind of hidden app, similar to MS internal apps (also sets servicePrincipalType=Legacy)
New-AzureRmADServicePrincipal: Creates an application for you and then creates the service principal (the app is visible in Portal, but the principal is only visible through the app's blade, because of missing tag)
New-AzureADServicePrincipal: Does not allow you to create it without providing an appId
If you want the principal to show up in the Enterprise Applications list as if you created it through the portal, you can provide the tag necessary with the v2 cmdlet:
New-AzureADServicePrincipal -Tags #("WindowsAzureActiveDirectoryIntegratedApp") -AppId ed5fa582-3991-4114-87da-30081c4105fb
The new v2 cmdlets are the best in my opinion, at least they allow you to create a service principal in a manner similar to what the Portal does. The ARM cmdlets are fine if your purpose is to create a service identity for using RBAC in the ARM API, as the principal is visible for that.
1 and 2 - probably it is using existing office 365 application in the tenant (I believe it is hidden)?
3 - Since you created a service principal, you need to look at enterprise applications in the Azure portal to see the service principals objects in your tenant (rather than the applications tab).
4 - this link
Application object
An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered, known as the application's "home" tenant. The application object provides identity-related information for an application, and is the template from which its corresponding service principal object(s) are derived for use at run-time.
Consider the application object as the global representation of your application (for use across all tenants), and the service principal as the local representation (for use in a specific tenant). The Azure AD Graph Application entity defines the schema for an application object. An application object therefore has a 1:1 relationship with the software application, and a 1:n relationship with its corresponding n service principal object(s).
Service principal object
The service principal object defines the policy and permissions for an application, providing the basis for a security principal to represent the application when accessing resources at run-time. The Azure AD Graph ServicePrincipal entity defines the schema for a service principal object.
Before an Azure AD tenant will allow an application to access the resources it is securing, a service principal must be created in the given tenant. The service principal provides the basis for Azure AD to secure the application's access to resources owned by users from that tenant. A single-tenant application will have only one service principal (in its home tenant). A multi-tenant Web application will also have a service principal in each tenant where an administrator or user(s) from that tenant have given consent, allowing it to access their resources. Following consent, the service principal object will be consulted for future authorization requests.
I am using Bluemix SSO service for user authentication and configured the Cloud Directory identity source as my identity provider. The SSO implementation is working perfectly fine for the Bluemix applications.
However, I have a need to add few custom user attributes and retrieve them as part of the user profile details once the authentication is successful. The Cloud Directory identity source only supports name & email as the user attributes and doesn't provide any feature to add additional custom attributes.
Is it possible to add any custom user attributes to Cloud Directory identity source? If not, what is the best way to configure the custom user attributes when using Bluemix SSO service?
It is not possible to add additional custom attributes using the Cloud Directory of Bluemix SSO (example: roles). There is not a best way to configure the custom user attributes, but you could develop your own login system. For example if you are using Bluemix nodejs runtime you could use the passport module and store all user information in a specific table of your DB. In this way you can manage the login and other custom fields. An alternative is to use SSO Cloud Directory, retrieve the username information from the SSO service in the session and use it as a key to retrieve other DB fields (roles, numbers, address).