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);
Related
i am quite new to kubernetes and I am looking towards certificate based authentication and token based authentication for calling K8 apis. To my understanding, I feel token based approach (openID + OAuth2) is better since id_token will get refreshed by refresh_token at a certain interval and it also works well with the login point(web browser) which is not the case with Certificate based approach . Any more thoughts to this ? I am working using minikube with kubernetes . Can anyone share their thoughts here ?
Prefer OpenID Connect or X509 Client Certificate-based authentication strategies over the others when authenticating users
X509 client certs: decent authentication strategy, but you'd have to address renewing and redistributing client certs on a regular basis
Static Tokens: avoid them due to their non-ephemeral nature
Bootstrap Tokens: same as static tokens above
Basic Authentication: avoid them due to credentials being transmitted over the network in cleartext
Service Account Tokens: should not be used for end-users trying to interact with Kubernetes clusters, but they are the preferred authentication strategy for applications & workloads running on Kubernetes
OpenID Connect (OIDC) Tokens: best authentication strategy for end users as OIDC integrates with your identity provider (e.g. AD, AWS IAM, GCP IAM ...etc)
I advice you to use OpenID Connect. OpenID Connect is based on OAuth 2.0. It is designed with more of an authentication focus in mind however. The explicit purpose of OIDC is to generate what is known as an id-token. The normal process of generating these tokens is much the same as it is in OAuth 2.0.
OIDC brings a step closer to providing with a user-friendly login experience and also to allow us to start restricting their access using RBAC.
Take also look on Dex which acts as a middleman in the authentication chain. It becomes the Identify Provider and issuer of ID tokens for Kubernetes but does not itself have any sense of identity. Instead, it allows you to configure an upstream Identity Provider to provide the users’ identity.
As well as any OIDC provider, Dex supports sourcing user information from GitHub, GitLab, SAML, LDAP and Microsoft. Its provider plugins greatly increase the potential for integrating with your existing user management system.
Another advantage that Dex brings is the ability to control the issuance of ID tokens, specifying the lifetime for example. It also makes it possible force your organization to re-authenticate. With Dex, you can easily revoke all tokens but there is no way to revoke a single token.
Dex also handles refresh tokens for users. When a user logs in to Dex they may be granted an id-token and a refresh token. Programs such as kubectl can use these refresh tokens to re-authenticate the user when the id-token expires. Since these tokens are issued by Dex, this allows you to stop a particular user refreshing by revoking their refresh token. This is really useful in the case of a lost laptop or phone.
Furthermore, by having a central authentication system such as Dex, you need only configure the upstream provider once.
An advantage of this setup is that if any user wants to add a new service to the SSO system, they only need to open a PR to Dex configuration. This setup also provides users with a one-button “revoke access” in the upstream identity provider to revoke their access from all of our internal services. Again this comes in very useful in the event of a security breach or lost laptop.
More information you can find here: kubernetes-single-sign-one-less-identity/, kubernetes-security-best-practices.
My app uses a SPA client and Phoenix/Elixir backend, with jwt authentication (via Guardian library). The app is deployed using Docker on GCP.
I'm having the below issue:
I'm an authenticated user that has been issued a jwt. Everything works fine.
The production application's docker image is rebuilt, redeployed, and the server is restarted.
My jwt token issued before the rebuild is no longer valid.
I'm having trouble finding what would be causing this. Looks like the secret key used in config.exs Guardian config will always be the same across builds.
Any help is appreciated!
Either the contents of the payload are being used to validate the message, and some field has changed in a way that the JWT is considered invalid by the server, or the secret actually has changed and your assertion is not correct.
The way I would problem solve this is by using a pre-developed tool to verify the JWT. Either your secret key can be used to validate the signature or it can't. No need to "guess".
After going through walkthroughs I had a test mvc app, test web api, and identityserver3 all working perfectly on my machine. I deployed IdentityServer3 to our servers in AWS behind a load balancer. I followed all the instructions in the Deployment wiki. I am able to hit the .wellknown configuration fine after deployment from a browser on my machine.
I changed the authority url for the mvc and api test apps to point to the aws deployment. Clients, Scopes, users, etc are all configured identically as they are hitting the same database as it was when running on local machine.
I can get an access token using RequestResourceOwnerPasswordAsync just fine so I think ids is installed fine.
However, both the API and the MVC app just trying to use implicit flow are now failing. FOr instance, when I try to hit a mvc controller action marked with [Authorize] I get an error stating "An invalid request URI was provided. The request URI must either be an absolute URI or BaseAddress must be set".
If I try to hit the webapi from the mvc app (both running locally on my machine) after a successful RequestResourceOwnerPasswordAsync call, I get the error "Response status code does not indicate success: 401 (Unauthorized)." after what seems like a timeout.
Any help would be greatly appreciated.
Figured out the problem. When specifying PublicOrigin, it has to be a full URL and not just the domain. I had left off https:// prefix.
The web api issue was related to connectivity to the identity server. There was some incorrect proxy settings for the app.
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'm using Azure mobile services with .net backend. My API controller works OK on my pc but as soon as I deploy it to Azure, Upon pinging from Postman gives "Authorization has been denied for this request." message with HttpStatusCode 401
Note that... I'm using table storage for storage instead of SQL Server and in the process removed all of Entity Framework related code. Also, None of the endpoints do not require any authentication.
Thanks.
The default authentication for mobile services is anonymous (i.e., no authentication required) when running locally, and application (i.e., at least the application key needs to be supplied).
If you're using Postman, try adding a "x-zumo-application" header to the request, with the application key (which you can get in the Azure portal) as the value. The request should work then.