First let me explain the problem:
We have an Android app and multiple customers. Each customer has their own endpoint (Kubernetes cluster of microservices basically) that the app should communicate with. To prevent us from having to deploy multiple versions of the app (one for each customer) we are looking for a solution that will use one app but allow for multiple endpoints.
I am interested in knowing if, and if so how, others have solved this.
We have tried:
Automatic endpoint resolution within the app based on user's domain. This fails our requirements because we then need to build a new app for every customer, which is not optimal with 10's of customers appearing every week.
Microservice that gives the user and endpoint based on user's domain. This fails because it creates a Catch 22 problem... how do we know the endpoint to this microservice?
Keycloak User Attributes. We use Keycloak for SSO. Using the REST API in Keycloak requires an admin user, but we do not want to expose such an admin user from any external application.
Manual endpoint insertion in the app. Highly user-unfriendly!
Related
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I'm just starting a new project. The result will be an API server and a progressive web app. The API server is implemented with TypeScript and the NestJS framework, the client with Angular 6.
I've been flirting with keycloak for some time. Still, I'm not quite sure it's right for me yet. But I don't want to worry about things like token renewal anymore and find it sexy that Keycloak tells me how to create user roles.
What bothers me, is the following - integration. For my use case it is necessary that the login and all features like password reset and so on are part of my application. That means I want to create forms myself in order to be able to do this perfectly in my own design and not have a second translation process, etc. Keycloak themes are not an option. So is it possible to hide keycloak in such a way, or is it so complex that I shouldn't use Keyloak in the first place? Afaik there is already an issue with password resets - I can't request it from the user side but have to make an REST call to the admin endpoint - which is okay but not ideal since it requires me to do more server side logic ( and that is not why I want to use Keycloak).
In addition, Keycloak is too much about the GUI - which makes it difficult for me, especially during development. Because I also want to provide my team with a local instance of keycloak during development. But what is the concept to import the initial data into realms, apps and also users into Keycloak? I found some JSON imports - but so far only for realms and apps. Is there also a function to import a whole dumb?
So that my team builds on a pre-built setup and has a user for each role. A reproducible setup with Vagrant or Docker which contains the import of initial data - that would be the goal.
So in short my questions:
Is it still worth the effort using Keycloak if I want to use everything via the API or should I simply use Passport and JWT?
Can I have a reproducible setup during my development that includes realms, apps, users, user roles, etc?
So, the question asked few months ago, but I also faces with that question, and I want to answer on it.
I think that you don't need Keycloak, it is fairly enough for you to use OAuth2 and JWT.
Let's justify my answer:
You have just one client - Angular application. Keycloak useful, when you have many clients (web-js, mobile platforms) and you want to create and manage them dynamically. But, I think that, in your case, you create your client once without modification in the future.
Also, Keycloak very useful, when you have a lot of integration with third part systems (Google, Fb, Twitter and etc) because Keycloak has them out-of-box. Or you need to integrate with some SAML or LDAP provider.
You may use Keycloak, if you need some Identity and User management platform, and when you have complicated user access flow.
In the end, you could consider Keycloak, if you need SSO (Single Sign On) feature. Once logged-in to Keycloak, users don't have to login again to access a different application. But, by your description, you have just one application.
Keycloak offers features such as Single-Sign-On (SSO), Identity Brokering and Social Login, User Federation, Client Adapters, an Admin Console, and an Account Management Console.
It's an out of box solution for rapid security layer development of application.You could have single common security layer for multiple application .
You can implement you security mechanism without using keycloak.
I have tried Google with queries similar to the title of this question, but haven't found anything useful.
Background: I am building a web app and would like to add a user authentication level to it. I cannot imagine anything worse than building a user authentication system from the ground up, so I want a quick solution.
I'm looking for open source software I can host on my server that provides an auth layer I can connect to, with multiple user accounts
Criteria:
I want to host the software on my own server
Provide a log in screen that works with multiple sign in strategies - twitter, facebook, vanilla email, etc.
Persists users to a database (preferably postgres) and persists session data
Preferably lets me store a minimal amount of data per user, like key value store
Has a client-side (Javascript) API, like Facebook's JS, so I can use this auth service on multiple sites. Namely, I want to use it on localhost or my own file system (when allowing file cookies). Client side JS API exposes methods like log in / log out
Has a server side API (such as exposes local RESTful endpoints) so that when I do build out my server side app for other data storage outside of the user, my app can query the auth service for log in status.
I want to run this stack completely independently of my own app - in fact I want to run this auth service and purely communicate to it from my local dev environment without building any server side app of my own.
I have used Firebase and they do many of the things that I want, including log in strategies and the client / server side APIs, but I want to be able to host my own version of this.
I can't imagine anyone takes pleasure out of building user authentication of any kind, so I'm surprised I haven't found anything in research.
I also know this is an open-ended question, but as far as I can tell I haven't found anything satisfying my requirements.
I like Devise (https://github.com/plataformatec/devise), which is for Rails. It has an active community with a boatloads of plugins available that can fulfill many of your requirements.
I didn't see a language specified; most languages and frameworks have their own implementations. Can you provide more information?
Example: I use the Flask framework on python. In addition, I use the Authomatic library which provides Oauth access for twitter, google, facebook, etc.
What I was looking for is something called a Single Sign On solution. According to this list there is nothing currently that meets my criteria.
Instead I have chosen to just run a local webserver and implement a regular auth flow.
I would like to have some guidance regarding how to handle authentication for my restful service to be able to support a couple of different scenarios, see included image?
I've been thinking about this problem for a couple of week without finding a solution for all of the cases and even if I'll make trade offs I'll be running into problems
If we skip the Mobile application and the use of Curl, there's no need to expose the service to the public and it would be possible to use basic authentication for the server to server communication. But we'll still need to put some responsibility at the "Web site for ninjas only" to pass the (openid authenticated user) as part for the http header?
In this case we're using Google apps to manage credentials for our co-workers and I don't like the idea to manage another username/password within the service if it's possible to avoid.
Is there any sustainable solution for my dreams, so that I can build awesome features for the client and implement a tight api that manages the authorization for different resources for a specific user?
Another possible to solution might be to integrate the service with the openid provider, but then I'll have problem with passing the user from "Web site for ninjas only"
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?