I recently started exploring the Gravitee API Platform.
One thing that I was trying to do was configuring a single plan to validate incoming JWT tokens from multiple Keycloak realms.
Is this possible to achieve?
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.
Running into issues with multiple instances of IdentityServer4 on Kubernetes exposed by the load balancer. I dont think there is a issue with credential login, my issues are around JWT Tokens. Works fine when there is only 1 instance.
Overview:
IdentityServer4
MongoDB Data Storage
PersistedGrantStore
Data Protection setup on Redis
Multiple .Net Core 3.1 Web API. Using AddIdnetityServerAuthentication in start up passing in the connection and the API Name. I am running multiple instance of the API. Reducing down to 1 I still get the same issue. Works fine if there is only 1 instance of the Identity Server but multiple instances I get the following error on the API:
"Bearer" was not authenticated. Failure message: "IDX10501: Signature validation failed. Unable to match key:
I am not getting any errors or failed authentications on the IdentityServer logs.
So the questions going on in my head is, JWT token so in I believe the request should be validated by the token, i.e. the API should not be requesting info form the Identity Server? Identity Server has DataProtection setup running on Redis as its store, I can see its dropped info in there. I have persisted grants store, but tokens are not added.
Do I need to switch to resource vs JWT? What is likely overhead for that?
Are the tokens not getting shared between the API instances via Data Protection?
Thanks for any advice / suggestions.
In case anyone else comes across this. It was down to mistakenly leaving developer signing in the config of Identity Server. Replaced with a certificate solved the issue.
builder.AddDeveloperSigningCredential();
to
builder.AddSigningCredential(rsaCertificate);
I'd like to use some of the more advanced features of the REST Dataset in Azure Data Factory (mainly pagination), but I can't see where to use Certificate Authentication. I have an HTTP Dataset working well with Certificate Authentication, but the only options seem to be:
Anonymous
Basic
AAD Service Principal
Managed Identity
Is there some way to use the AAD Service Principal or Managed Identity with a certificate? Maybe I can do this using the Advanced settings?
The docs say that the HTTP connector is "less functional comparing to REST connector" but this seems to be a pretty big omission from the REST version.
Is there some way to use the AAD Service Principal or Managed Identity
with a certificate? Maybe I can do this using the Advanced settings?
SP and MI can't be applied for the certificate authentication, for AAD instead. please refer to this simple blog.
Based on the REST Connector document,it only supports above 4 types of authenticate options. If you want to carry certificate with request,please use HTTP connector.
We are considering to use the keycloak as our SSO framework.
According to the keycloak documentation for multi-tenancy support the application server should hold all the keycloak.json authentication files, the way to acquire those files is from the keycloak admin, is there a way to get them dynamically via API ? or at least to get the realm public key ? we would like to avoid to manually add this file for each realm to the application server (to avoid downtime, etc).
Another multi-tenancy related question - according to the documentation the same clients should be created for each realm, so if I have 100 realms and 10 clients, I should define the same 10 clients 100 times ? is there an alternative ?
One of our flows is backend micro-service that should be authenticated against an application (defined as keycloak client), we would like to avoid keeping user/psw on the server for security reasons, is there a way that an admin can acquire a token and place it manually on the server file system for that micro service ? is there a option to generate this token in the keycloak UI ?
Thanks in advance.
All Keycloak functionality is available via the admin REST API, so you can automate this. The realm's public key is available via http://localhost:8080/auth/realms/{realm}/
A realm for each tenant will give a tenant-specific login page. Therefore this is the way to go - 10 clients registered 100 times. See more in the chapter Client Registration of the Keycloak documentation. If you don't need specific themes, you can opt to put everything in one realm, but you will lose a lot of flexibility on that path.
If your backend micro service should appear like one (technical) user, you can issue an offline token that doesn't expire. This is the online documentation for offline tokens. Currently there is no admin functionality to retrieve an offline token for a user by an admin. You'll need to build this yourself. An admin can later revoke offline tokens using the given admin API.
I am currently playing around with the Kong API Gateway and I would like to use it to validate the authentication of users at the gateway and restrict access to services if the user is not logged in properly.
I have an authentication service which issues JWTs whenever a user logs in.
I would now like to share the JWT secret with Kong and use it for validation of the issued JWTs to secure services which need proper authentication.
I had a look at this plugin: https://getkong.org/plugins/jwt/
But it seems that this plugin works a bit different than what I would like to achieve. Why do I have to create consumers? I would like to have only one user database at my authentication service to avoid the need of synchronisation. It seems that the approach of this plugin is designed for giving 3rd party stakeholders access to my API.
Any hint would be highly appreciated.
The answer given by Riley is sort of correct in implementation but that is not the intended use of a consumer in the Kong.
A consumer in kong is the application that is is using the API. So, unless you have multiple vendors using your app/web service, I suggest you create a single consumer.
You can create multiple key and secret pair(JWT credentials) for that consumer. Create a JWT for a user by using the users Key and secret. Store this Key and secret in your current database along with your userID and other details. Create your JWT using these and return the JWT to the user.
Anything else you want to append as a claim can be added to the JWT while you are creating it. You can create a check for these claims in Kong. So, when you get a call to any of your APIs along with these JWT Kong will check the validity of the JWT(along with all the claims) and only then allow the access to the API.
It seems to me that the design of the JWT plugin for Kong doesn't want to share a JWT secret with you - it wants to own the JWTs entirely. You will indeed have to create a consumer per user, and let Kong manage that.
I asked a few questions to confirm on the Google Group - see https://groups.google.com/forum/?fromgroups#!topic/konglayer/XHnVEGoxZqo
Two highlights:
Can you just confirm that it should be OK to make one consumer and one credential per user?
Not only that's okay, but that's the recommended way :)
and
Will Kong be happy to have two million consumers of a single api? What about 200 million?
Technically that shouldn't be an issue, I would recommend setting up a POC where you can experiment with a higher number of users, in order to optimize the connection between Kong and the datastore and make sure we tune everything properly.
You can actually pass the secret to the JWT plugin when you create it:
$ curl -X POST http://kong:8001/consumers/${consumer_id}/jwt \
-H "Content-Type: application/x-www-form-urlencoded" \
--data "secret=mysecret&consumer_id=${consumer_id}"