I have a keycloak deployment where I am federating users from a legacy DB. So far this is working good. Now I'm trying to add some clients that will be our API users. Creating, adding roles, and creating a service account seems to be all good as well.
But I need these service accounts to be in table where my federated users are. My app uses ACLs which based on my user table.
I don't see anything in the develop guide. Is this possible?
Related
I'm trying to do limit access to my application using WSO2 identity server.
In summary, a contracting company will send us a list of authorized usernames and, using WSO2, we want to be able to federate access and authorize only those usernames into each application of ours.
The general setup is: my WSO2 server will act as a federation hub to various external identity providers (IdP). These IdPs will contain their own user tables with all the users of their third party company. However, only some of those users should have access to our application (to charge by user count), as demonstrated by this diagram.
So far I've been able to
login into the application using WSO2;
Federate authentication from WSO2 to the external IdP; and
I'm able to restrict access to the application with XACML policies based on the user's role.
However, all the attributes currently come from the external identity provider, so in this scenario, they would actually be in control of who has access to the application. What I want is to be able to use their IdP for authentication, and my WSO2 instance for authorization.
Could you shed some light on how to achieve this?
TL;DR:
We need JWT Auth on an API that is customers specific
Each customer has an API.dll in their own application pool and site on IIS
We need 3rd party BI solutions to be able to securely call the API
We need single users from the customer database to be able to call the API with their existing username and password
Details
At my job we have created a somewhat simple rest API we need authentication for.
The thing is, that the API is not shared between customers. So each customer gets a DLL that is set up to read/write to individual databases.
We would like our API to be usable by 3rdparty systems that our customers use, e.g. BI solutions - as well as user login (the specific users of our system).
Current setup
Each customer has their own: database, application pool, site, desktop app and api.dll (running on IIS)
Customers are free to create any number of users in our desktop application and grant these users varying rights. These users are not centralized across customers. So we have no information about a customers created users (unless we look in their database)
If the customer is self hosted they control the API and the authentication on their server.
If we host their solution we create an active directory user for that customers API and enable basic authentication for that site, granting permission for that single user.
Question
How can auth be set up for this somewhat weird situation, allowing single user authentication as well as allowing 3rd party integrations?
As I understand from my reading we need some kind of hybrid between grant_type: password and grant_type:client_credentials.
As with anything job related, time is a huge factor, but I want the solution to adhere to standards and best practices as closely as possible.
We currently have Azure Active Directory with several thousand users in Active Directory. What does IdentityServer4 provide that I cannot get with connecting my .NET and/or Java apps to AAD alone? Can AAD provide me with an auth token that can be used to access the front-end app as well as the back-end API?
The key benefit is control (you can model your clients and resources and taylor your UX as you see fit) and the ability to use it as a federation gateway. E.g. if you need to support multiple customers many of which may want integration to their own IDP.
Is a Service Account intended to be created in an application’s domain? Or in a clients G Suite Domain, on behalf of the application?
Background:
My company has a product (hereafter “The App”) which has several thousand organizations as clients, each potentially having their own Google domains. (hereafter “Organization Domain”)
We are looking to set up a sync between The App and the Organization Domain, for data that is common between The App and the Organization Domain, and want to use an OAuth2 connection, with a domain admin granting The App ‘domain-wide authority’ on behalf of their users, for offline syncing.
From the Service Account page:
... an account that belongs to your application instead of to an
individual end user. Your application calls Google APIs on behalf of
the service account, so users aren't directly involved.
and
G Suite domain administrators can also grant service accounts
domain-wide authority to access user data on behalf of users in the
domain.
Referencing the Cloud Platform Console Help Faq:
You can access data from your users' Google Cloud Platform projects by
creating a service account to represent your service, and then having
your customers grant that service account appropriate access to their
cloud data using IAM policies. Note that you might want to create a
service account per customer... (emphasis added)
It sounds like The App should be able to create a single Service Account, which all of our clients authenticate into for their Organization Domain.
The part that’s unclear:
In the Service Account page, the instructions for delegating domain wide authority seems to shift concerning where the Service Account is.
Before the instructions, it reads:
... first enable domain-wide delegation for an existing service
account in the Service accounts page ... with domain-wide delegation
enabled. Then, an administrator of the G Suite domain must complete
the following steps:
Afterwards, it reads
Your application now has the authority to make API calls as users in
your domain (to "impersonate" users). (emphasis added)
From what I’m reading, the first part reads "one Service Account for The App", while the later reads as "the service account is only able to access as a person on The App domain, rather than the Organization Domain."
Is a service account intended to be created in The App's domain? Or in the Organization Domain, on behalf of The App?
I have seen examples that have the Organization Domain admin create a service account, and then pass over the clientID/secret to the owners of The App… but I’m not sure that’s the correct approach for our scenario.
Related - Scope management:
The delegation steps have the Organization Domain admin manually add scopes.
We’d prefer to use the OAuth consent screen, which shows the scopes, and has our pages/policies linked.
Unfortunately, as far as my research has uncovered, it doesn’t look like that page is used in the Service Account authorization flow; just for other application types, which authenticate a single user, as opposed to an entire Organization Domain.
Is there a page I’ve missed in Google’s sea of documentation?
I think you are miss understanding the use of Service accounts.
Service accounts are dummy user accounts. They have their own drive account, calendar account and probably a few more. Service accounts are designed for use with back end applications server to server communication where there is no user interaction. Service accounts are preauthorized. You grant the service account access to the user data in your case by using domain wide dedication to the gsuite account. This way the service account would be able to for example send control all the users google calendar accounts.
This is why you dont need a consent screen. Another point with service accounts is you must control the data in order to set this up. If you dont control the data then you cant grant the service account access to that data.
You should be using Oauth2 if you want to access private user data owned by your customers.
As for the rest of your question is very broad and i am not really user where to start with it you might want to break it up into several questions. Take them one at a time. I am not sure i understand what it is you are trying to do so i dont think i can try to answer that part.
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).