Apparently the best practice for storing microservice config settings is in the tenant options.
But I have a use case where the microservice is multi-tenant and I want a common configuration for all tenants stored in one place.
I got a tip to use the tenant options of the tenant that is the microservice owner (see application owner, https://cumulocity.com/guides/reference/applications/#application). I'm thinking of a solution along these lines - on startup, the microservice looks up the id of its owner tenant and looks for config settings in the tenant options. Is this a viable approach and is it safe to assume that the owner tenant is subscribed to the microservice, so that the service has read privileges?
Technically it is not given that the owner tenant is subscribed to the microservice as well. You will just need to ensure that.
If you want to have a common configuration the owner tenant is the best place.
Related
I am in the process of adding an Identity Server 4 implementation to serve authentication and authorization for a ASP.NET Core Web API. Clients will be a native iOS app, and MVC web app and potentially an Angular SPA later down the line.
I am able to provide tokens on an « offline access » basis to the iOS client using AppAuth - which is great.
I am just not sure about some of the architectural choices to make:
1/ where should the registration of new users take place? The literature recommends that the IS4 server be limited to login and logout endpoints, for security purposes. Does that mean that the clients or the APIs should handle creation of users in the store? I thought the whole point of IS4 was that clients and APIs don’t have access to the store? It would seem logical that the addition and modification of users be handled by the only part of the system that has access to the store, no?
2/ is it safe to persist (1) tokens (2) the user store and (3) business data ok the same database - different tables but same database on same server? Is it better to separate databases?
3/ is it safe to have the Identity server app hosted on a sub domain to the domain where the client app will live? The API is already on another sub domain on this same domain.
Thanks
1/ where should the registration of new users take place? The literature recommends that the IS4 server be limited to login and logout endpoints, for security purposes. Does that mean that the clients or the APIs should handle creation of users in the store? I thought the whole point of IS4 was that clients and APIs don’t have access to the store? It would seem logical that the addition and modification of users be handled by the only part of the system that has access to the store, no?
You can extend IDS4 to add user management. Per IDS4 docs it is a middleware that adds the spec compliant OpenID Connect and OAuth 2.0 endpoints to an arbitrary ASP.NET Core application. But this doesnt mean that you can not extend it. Here is a sample.
2/ is it safe to persist (1) tokens (2) the user store and (3) business data ok the same database - different tables but same database on same server? Is it better to separate databases?
This depends more to your deployment model and your considerations for availability and scalability rather than safety. I suggest you to read more here to be able to make the best decision.
3/ is it safe to have the Identity server app hosted on a sub domain to the domain where the client app will live? The API is already on another sub domain on this same domain.
This again has nothing to do with safety as is more of availability/scalability matter
I have thoughts as following:
1/ where should the registration of new users take place? The
literature recommends that the IS4 server be limited to login and
logout endpoints, for security purposes. Does that mean that the
clients or the APIs should handle creation of users in the store? I
thought the whole point of IS4 was that clients and APIs don’t have
access to the store? It would seem logical that the addition and
modification of users be handled by the only part of the system that
has access to the store, no?
Suggestion: If I am starting applications from scratch and there is no existing interface for user registration, then I will prefer to provide user registration flow as part of IdS.
2/ is it safe to persist (1) tokens (2) the user store and (3)
business data ok the same database - different tables but same
database on same server? Is it better to separate databases?
Suggestion: Both options are fine, but best one, is one, which suitable to your application architecture. For example if I have Service oriented or Microservice architecture, then separate database is more feasible. But if you have only one application as user registration point and other applications will use that database as user store, then it is already part of an application database. I may prefer to have IdS tables in separate Database until, unless there is some limitation.
3/ is it safe to have the Identity server app hosted on a sub domain
to the domain where the client app will live? The API is already on
another sub domain on this same domain.
Suggestion: if you are serving multiple organizations, then IdS can be on different domain, otherwise, it is generally practiced to be on sub domain.
Right now I've only requested the permissions required for a user to successfully authenticate into the SaaS application. These are delegated permissions.
I'm now wondering how to handle permissions for a new daemon integration, which will request different data from Graph and require application permissions. So far I see these alternatives:
I create a new application, representing the integration, and if the customer wants to enable this feature they go through the admin consent flow and grant the required application permissions.
I encumber the main app with the 'optional permissions' and tell the customers that if they don't use this particular feature then they can revoke this and that permission.
Are there more alternatives? How are others handling this situation?
I foresee more daemons, requiring different permissions, in the future which makes alternative 1) seem quite unattractive. On the other hand, I can envision push back from AD admins everywhere if I go down route 2) and ask for all kinds of permissions that aren't applicable to that organizations feature set.
Best practices would dictate you have a separate app registration for each application/daemon. That being said, if you don't want to, you could do something between your two options, make a second app registration for all the daemons, and make a simple SPA just to log in to give consent to that app registration, which is separate from the saas app registration.
I would definitely avoid option 2 on your list though, because then the saas application would technically be able to access all the same things your daemon permissions have which can be a big security risk.
I'm currently trying to migrate a multi-tenant system from a "custom" authentication and authorization implementation to OAuth2.
The multi-tenancy model is very similar to GitHub's structure, so I'm going to use it as the main example. Let's assume that in the application we have users, repositories and organizations. Users have access to repositories directly, or through organizations they are members off. Depending on their access rights, users should have different permissions towards repositories and the sub-resources (like /repository/issues), or organizations and their sub-resources (/organization/members) for users who manage them. Unlike, GitHub's OAuth2 solution, this system should be able to provide different levels of permissions across repositories or organizations (GitHub does it at a different level with a custom implementation).
The goal is to keep the logic as simple as possible, encapsulate everything in an authorization service and piggyback on OAuth2 as much as possible.
My approach was to deploy a generic OAuth2 service, and handle the permissions using dynamic scopes:
user:read
user:write
repo:read
org:read
repo:<repo_id>:issues:read
repo:<repo_id>:issues:write
org:<org_id>:members:read
org:<org_id>:members:write
This enables granular permissions for clients and users, such as a user being able to read + write issues in one of his repos, but only read in another.
While this seems to solve the problem, the main limitation is being able to request scopes. Since users would not know the ids for the repos and orgs they have access to, they are not able to request a correct list of scopes when contacting the authorization server.
In order to overcome this I considered 2 solutions:
Solution 1
Issue a token for repo:read and org:read
Retrieve list of repos and orgs the user has access to
Issue a second token with all necesarry scopes
On a deeper thought, this turns out not to be viable since it would not support grants like implicit for authorization_code unless the authorization server would deal with this "discovery" of resources.
Solution 2
The first 2 steps are common to the first solution, while for the 3'rd step, the users would only be able to issue tenant scoped tokens. By extending the OAuth2 with a parameter identifying the tenant (/authorize?...&repo=<repo_id>), clients using authorization_code grant would have to issue tokens for every tenant. The token issued on step 1 would have to persist the identity of the user on the authorization server and eliminate the need of re-authentication when a user would switch between tenants. The downside of this approach would be that it increases the complexity of client integrations and that it might defy the standard in some way.
I'm looking for a second opinion on this, which would possibly simplify the problem and make sure the solution adheres to the standard.
tldr; What about using self contained access tokens which convey user identity information and hold access policy defined at API endpoint ?
The problem you face right now is due to mismatch of what OAuth 2.0 scope is capable of. Scope value in OAuth 2.0 is defined to be used by the client application.
The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter.
But in your approach, you try to make it to be defined by end user (the human user).
A solution would be to make authorization server independent of permission details. That means, authorization server only issue tokens which are valid for your service/system. These token can be self-contained, holding user identifier and optionally organisation details (claims). It may contain other details that are required by your service (upto you to decide). Ideal format is to make it an JWT.
Once your client (the consumer of system, like GIT website) obtain this token, it can call the system backend. Once your system backed recieve the token, it can validate the token for integrity, required claims and use these claims to identify what resources are granted for this specific user. Permission levels you defined for scope now are stored with your service backend.
Advantage of this is the ability to let user identity to be reside anywhere. For example you can use Google or Auzure AD and as long as they can provide you a valid token, you can support such users to use your system. This is ideal as permissions are not stored in them. And super users will have ability to define and maintain these permissions.
Agree with everything mentioned by #Kavindu Dodanduwa but would like to add some additional details here.
This problem indeed stays beyond what standard OAuth 2.0 covers. If you want to manage permissions per-resource (e.g. per repo or organization) this should be handled in your service or a gateway in front of it. Typically you need some kind of access-control list (ACL) stored on your backend which you can then use to authorize users.
If you'd like to look at existing standards check out XACML and UMA (which is an extension of OAuth 2.0). However I find them rather complicated to implement and manage especially in distributed environment.
Instead I'd suggest an alternative solutions using a sidecar for performing authorization on your service. Check out related blog posts:
Building a fine-grained permission system in a distributed
environment: Architecture
Building a Fine-Grained Permissions
System in a Distributed Environment: Implementation
Open Policy Agent could be a good solution for such architecture.
I'm writing a cloud based multi tenant application. I'd like tenants to manage their own users - add, remove users - manage permissions etc. I'm kind of hoping there is a provider out there that already handles this. I don't want to have to write all those screens. I'd rather set up the list of roles and permissions and let the tenant admins go in and manage their users.
All I want if for a logged in user to get a list of permissions. I can code against those permissions in my application.
Does such a thing exist?
Disclosure: Answer provided by an Auth0 employee.
If I understood correctly you should be able to accomplish your goals using Auth0 solutions aimed at multi-tenant applications. There are a couple of resources that should help you get started, although I would give particular focus to Using Auth0 with Multi-tenant Apps.
In the section (A single Auth0 account for all tenants) you'll notice that the simpler management option would be to only have a single Auth0 account, however, your use case could be accomplished by having each tenant have their own separate account which would make it possible for them to manage their users from Auth0 built-in dashboard. (no need for you to write custom screens)
One account for all tenants is simpler and allows you to manage them in one place.
Only if you want to share access to the dashboard with tenants would a separate Auth0 account per tenant be required.
Also check section (Different roles for each tenant) for a possible way on how to handle your user role and permission information.
Additionally, there's a sample multi-tenant app where each tenant has its own Auth0 account on Github if you want to delve into the more technical aspects.
On the other hand, if your tenants already have their own authentication solution in place you can easily integrate that with your Auth0 enabled SaaS application. See Building multi-tenant, SaaS applications with Azure AD and Auth0 for a detailed example on Azure AD integration, but don't think you would be restricted only to Azure AD integration as Auth0 supports a wide range of identity providers (Identity Providers Supported by Auth0).
all. I wonder if I can get the tenant ID except for carbonContext API. I see this set of API can get anything from the server, but it is too powerful to be exposed the the developers. An evil dev-er can easily get the whole osgi services. He can even modify other users's registry by just setting the tenantID to others. So is there any method I can use, to get the tenant ID of an app?
Normally tenant ID is an internal detail and it is not exposed via web services. AFAIK Only available way is the CarbonContext API. Actually you can enable java security manager and restrict the access to OSGI service. I guess WSO2 has done it in their live deployment where we can not access CarbonContext, user realm and other service using a web app. But i agree that there must be a way to get tenant information about the deployed tenant. (basically tenant domain , not tenant id).