I implemented EF for identity server following this link
https://github.com/IdentityServer/IdentityServer4.EntityFramework
I see many tables/entities but not even single table for tokens.
https://github.com/IdentityServer/IdentityServer4.EntityFramework/tree/dev/src/IdentityServer4.EntityFramework/Entities
Is it correct behavior for production? How can I get token in database or it is not needed even on production?
Thanks
PersistedGrants table is where your tokens would be stored. Keep in mind only reference tokens, refresh tokens and authorization code is being saved for security reasons. You will see entries in this table once user logs in successfully. see this for further refrences!
You can also implement your own implementation for the grant store and add it in your startup like this:
services.AddTransient<IPersistedGrantStore, MyPersistedGrantStore>
Related
I have an existing API connected to an AWS PostgreSQL database that uses AWS Cognito for User authentication.
The goal is for users to insert data via the API with some field mapped to their Cognito id, and retrieve the same data. The idea would be for each user to only have access to the data 'owned' by them. Similarly to the way row level access works.
But I do not want to create a role for each user which seems to be necessary.
The idea would be that I need to somehow setup a connection to the PostgreSQL DB with the user_id without creating a user and handle the accessible data via a policy, or somehow pass the data to the policy directly.
What would be an ideal way to do this, or is creating a PG user for each user a necessity for this setup?
Thanks in advance
EDIT: I am currently querying the database through my backend with custom code. But I would rather have a system where instead of writing the code myself, the PostgreSQL system handles the security itself using policies(or something similar). I fully understand how PostgreSQL row-level-access works with roles and policies and I would prefer a system where PostgreSQL does the major work without me implementing custom back-end logic and preferably not creating thousands of PostgreSQL roles for the users.
You should not allow users to make a direct connection to the database.
Instead, they should make requests to your back-end, where you have business logic that determines what each user is permitted to access. Your back-end then makes the appropriate calls to the database and returns the response to the user.
This is a much 'safer' response because it prevents users having direct access to your database and it is also a better architecture because it allows you to swap-out the database engine for another one without impacting your service.
The database is for your application, not for your users.
We already have DB with users.
We have to migrate all records to Keycloak DB or we can just implement Storage SPI ?
We don't want to migrate records, because we should also support old DB, it brings problems because we will need synchronize 2 DB.
Can you please write what could be the problems in this approach and write your advices for resolve theirs ?
USER DATA SOURCES
Moving to a system such as Keycloak will require an architectural design on how to manage user fields. Some user fields will need migrating to an identity database managed by Keycloak. Applications can then receive updates to these fields within tokens.
KEYCLOAK DATA
Keycloak will expect to have its own user account storage, and this is where each user's subject claim will originate from. If a new user signs up, the user will be created here before being created in your business data.
Keycloak user data will include fields such as name and email if they are sent in forgot password workflows. You can keep most other user fields in your business data if you prefer.
So to summarize, a migration will be needed, but you don't have to migrate all user fields.
BUSINESS DATA
This may include other user fields that you want to keep where they are, but also include in access tokens and use for authorization in APIs. Examples are values like roles, permissions, tenant ID, partner ID, supscription level.
DESIGN STEPS
My recent blog post walks through some examples and suggests a way to think through your end-to-end flows. There are a couple of different user data scenarios mentioned there.
It is worth doing a day or two of sketching out how you want your system to work. In particular how your APIs will authorize requests, and how you will manage both existing and new users. This avoids the potential for finding expensive problems later.
I'm developing a microservice (restful) project that uses kaycloak as IAM. I could create realm, client, users,... for authenticating but my concern is should I manage users only on keycloak or creating my own user table in my microservice?
is should I manage users only on keycloak or creating my own user
table in my micro-service?
First you need to check what can one do (or not) with Keycloak regarding user management and compared with your current (and possible future) requirements. If it does not completely fulfill your requirements then you can either extend Keycloak, adapt your requirements, or (probably the most straightforward solution) have your own user table in your micro-service.
You might want also to create your own user table for performance reasons. Depending on how slow it is to access Keycloak in your setup you might consider using that user table as caching mechanism for quick access of user-related information.
The problem of having that user table is that depending on the user information stored on Keycloak and on the user table you might have to keep them in sync. Moreover, if that information exists on the user table and not on Keycloak, and you need that information on the tokens, you will have to think about how will you handle such situations.
Personally, I would try to avoid creating the user table unless it is really necessary. So a complete answer to your question will most-like be highly dependent of your own needs.
I’m currently working on a PoC with multiple Quarkus services and Keycloak RBAC. Works like a charm, easily to bootstrap and start implementing features.
But I encountered an issue that I could not solve in my mind. Imagine:
User accesses a protected service
quarkus-oidc extension does fancy token obtaining by HTTP redirecting, JWT in cookie lasts 30 minutes
User is authenticated and gets returned to the web application
User works in application, fills in forms and data
Data is being stored by JWT-enriched REST calls (we do validation by hibernate-validator)
User works again, taking longer than 30 min
Wants to store another entry, but token from step 3 is now expired and API call fails
User won’t be happy, so me neither
Possible ways to solve:
Make the JWT last longer than the current 30 minutes, but that just postpones the issue and opens some security doors
Storing users’ input in local storage to restore it later after a token refresh (we also would do that to not loose users’ work)
Refresh the token „silently“ in JS without user knowing. Is there a best practice for that?
I missed something important and the internet now tells me a better architecture for my application.
Thank you internet!
Re the step 3. In Quarkus 1.5.0 adding quarkus.oidc.token.refresh-expired=true will get the ID token refreshed and the user session extended if the refresh grant has succeeded
For such use cases, I tend to prefer the reverse of JWT. I keep the user data in a shared data service (a data grid like Infinispan or Redis). So that this data is keyed by the user and available. I do control the TTL of that data in the shared data service.
It can either be specific to an app, or shared between a small number of apps. It does bring some coupling but so does the JWT property structure.
For Quarkus, there is an Infinispan client integration, a Hazelcast one, mongodb and AWS dynamoDB. And you can bring other libraries.
I have not been able to divine the way I might add extra claims from my application database. Given my limited understanding, I see two ways:
After successful authentication have keycloak pull extra claims from the application database somehow. This app database is postgres, for example.
Have the application update the jwt with extra claims using a shared key.
I would like some feedback both paths. I feel that the fist option may be safer. However I am not sure where to begin that implementation journey.
Answering my own question here. I cross-posted this question to the Keycloak users mailing list here (http://lists.jboss.org/pipermail/keycloak-user/2017-April/010315.html) and got an answer that seems reasonable.
This is pasted from the answer I received there.
I use the first option. I do it with a protocol mapper, which is a convenient place to do it because there the token is already built by keycloak but hasn't been signed yet. This is the procedure :
User logs in
My custom protocol mapper gets called, where I overwrite the transformAccessToken method
Here I log in the client where the protocol mapper is in into keycloak, as a service. Here don't forget to use another client ID instead the one you're building the protocol mapper for, you'll enter an endless recursion otherwise.
I get the access token into the protocol mapper and I call the rest endpoint of my application to grab the extra claims, which is secured
Get the info returned by the endpoint and add it as extra claims