What can it be for, what logic can be there?
I suppose there should be a connection to keycloak, maybe checking access to create roles and users, am I right or wrong?
It may mean that you need to deploy Keycloak in its own container, separate from the apps.
Related
Good morning,
we have a use case that involves 2 different Windows environments, in which the applications should authz against a keycloak server.
The first environment contains the leading AD, which is replicated once a day into the second environment, since the second environment must not query the AD of the first one. This is a firewalling policy.
Now our thought is to use keycloak as a “bridge” between the two environments, having a keycloak server in the first environment reading the AD with user federation turned on.
In the second environment the keycloak server somehow replicates with the first one, in the best case via HTTPS (which could pass the firewall) so the applications and users in the second environment can authz with the same credentials as in the first environment.
Is there a way to achieve this or something similar?
thx in advance
Frank
My requirement is such that i have an application authenticated via keycloak. Suppose if my current keycloak fails i need a second instance of the keycloak to run in parallel without any downtime.
Can someone provide some reference on how to create 2 or more instance and such that if one fails the one one can continue providing authentication
Thanks,
Radhakrishnan
A clustered installation of Keycloak would allow for high availability and tolerate the failure of a single instance. The Keycloak and Wildfly documentation referenced below explain the particulars:
https://www.keycloak.org/docs/latest/server_installation/#_clustering
http://docs.wildfly.org/18/High_Availability_Guide.html#JGroups_Subsystem
In cloud foundry how can I get the client_id and client_secret code.
This will be used in Basic authentication instead of passing the user and password for respective api calls
In general, this is something that you would get from your platform administrator. He or she would be able to provide you with a properly configured client id and client secret to fit your needs. If you are not the administrator, then you won't be able to do this.
If you are an administrator, read on. There are many existing client and secret pairs within a Cloud Foundry platform. It's also possible, and suggested, to create custom client and secret pairs for use with non-platform apps. You shouldn't use a platform client for your custom app, you should use your own custom client, that way if the client is compromised you can delete it or change the secret.
All of this, viewing & managing client data, is done through UAA, so I'd recommend starting with the docs on UAA. Make sure that you understand the concepts. You may even want to take a step further back and review concepts of OAuth2 as well. Understanding OAuth2 will make working with UAA much easier.
https://docs.cloudfoundry.org/uaa/uaa-overview.html
After that, you'll need the uaac (i.e. UAA client) installed.
https://github.com/cloudfoundry/cf-uaac
Once you're familiar with UAA & have the client installed, this doc on how to manage clients should provide you with instructions to view or create a new client.
https://github.com/cloudfoundry/uaa/blob/master/docs/Sysadmin-Guide.rst#manage-client-registrations
You will need admin role to be able to create a client or get its details.
Refer https://docs.cloudfoundry.org/api/uaa/version/4.7.1/index.html#clients to see various api to manage and create clients.
You can also use the uaa client to get the client details.
Refer https://docs.cloudfoundry.org/uaa/uaa-user-management.html for more info.
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.
How can I create multiple instances of a bundle that consumes an external webservice?
An external webservice requires clients to logon before using the services. I have multiple accounts. The problem is I want to be able to add multiple instances; one for each account. Each instance is an osgi declarative service that consumes the external service.
Do I have to deploy a new bundle for each account? This does not feel like the right way to solve this.
What you need is multiple instances of an OSGi component or service, not multiple instances of a bundle.
I'd recommend a service factory, where each OSGi config that you create (account parameters in your case) for your service causes a new instance of a service to be created.
Neil Bartlett's tutorial at http://njbartlett.name/2010/07/19/factory-components-in-ds.html looks like a good starting point for that.
Is that bundle under your control - can you refactor it ?
If yes, it might be useful to expose a client factory service, rather than client service itself.
Then each instance can log into a different account.