I would like to create realms with a specific configuration. Currently I'm calling Keycloaks endpoints after realm creation to configure it. This is quite slow and doesn't feel intuitive.
Are there any alternatives for specifying how a realm is created by default?
Related
I want to do OpenID Connect 1.0 authentication for frontend users on my site.
In order to do so, I've developed an authentication service (as described in the docs). Within this service I'd like to access TypoScript configuration values to fetch the OpenID configuration (.well-known-URL, client ID and secret).
To do so, I simply inject TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface into the authentication service - but this class only wraps the real configuration manager, which in this case is an instance of TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager - although I am in frontend context. This also affects other places, for example is TYPO3 not able to get the correct plugin configuration (because it is not present in the backend).
I've tracked this down to TYPO3\CMS\Extbase\Configuration\ConfigurationManager::initializeConcreteConfigurationManager, where the existence of $GLOBALS['TYPO3_REQUEST'] is checked - if it does not exist, the BackendConfigurationManager is used as fallback.
So my question: How do I correctly fetch TypoScript configuration within a TYPO3 authentication service?
As already written by Chris. TypoScript is not initialized at this time and I also don't suggest to do so by yourself.
Your options are:
Use the extension configuration which is described here
Use the site settings which are described here
Which one you want to use depends on the usecase. The extension configuration is global and even more lowlevel as now site is used. If you need different setttings for a multi-site installation, the site settings are the prefered choice
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.
I have setup Keycloak as a SAML broker, and authentication is done by an external IdP provided by the authorities. Users logging in using this IdP are all accepted and all we need from Keycloak is an OAuth token to access our system.
I have tried both the default setup using H2 and running with an external MariaDB.
The external IdP provides us with a full name of the user and a personal ID. Both data are covered by GDPR and I really do not like the sound of storing that data in a database running in the DMZ. Opening up for Keycloak to access a database in the backend is also not a good solution, especially when I do not need users to be stored.
The benefit of running without a database is that I have a simpler DMZ setup as I really do not need to store anything about the users but on the backend.
Do I need a database, and if not how do I run Keycloak without it?
Do I need a database, and if not how do I run Keycloak without it?
Yes, however, out-of-the-box Keycloak runs without having to deploy any external DB. From the Keycloak official documentation section Relational Database Setup one can read:
Keycloak comes with its own embedded Java-based relational database
called H2. This is the default database that Keycloak will use to
persist data and really only exists so that you can run the
authentication server out of the box.
So out-of-the-box you cannot run Keycloak without a DB.
That being said from the same documentation on can read:
We highly recommend that you replace it with a more production ready external database. The H2 database is not very viable in high concurrency situations and should not be used in a cluster either.
So regarding this:
The benefit running without a database is that I have a simpler DMZ
setup as I really do not need to store anything about the users but
on the backend.
You would still be better offer deploying another DB, because Keycloak stores more than just the users information in DB (e.g., realm information, groups, roles and so on).
The external IdP provides us with a full name of the user and a
personal ID. Both data are covered by GDPR and I really do not like
the sound of storing that data in a database running in the DMZ.
Opening up for Keycloak to access a database in the backend is also
not a good solution, especially when I do not need users to be stored.
You can configured that IDP and Keycloak in a manner that the users are not imported to the Keycloak whenever those user authenticate.
I've read many tutorials on setting up a realm in Keycloak but it's nowhere mentioned that Keycloak is creating a client called <your-realm-name>-realm in master realm with set of roles:
Why is it needed?
Is the custom realm a form of a client for a Keycloak itself so it needs to create a kind of "virtual" client to handle that relation?
This automatically created client has a set of roles which look to me like a Keycloak internal roles:
Where can I find them in a documentation?
Is the custom realm a form of a client for a Keycloak itself so it
needs to create a kind of "virtual" client to handle that relation?
Kind of; from the Keycloak Documentation itself:
The master realm is a special realm that allows admins to manage more
than one realm on the system. You can also define fine-grained access
to users in different realms to manage the server.
The master realm in Keycloak is a special realm and treated differently than other realms. Users in the Keycloak master realm can be granted permission to manage zero or more realms that are deployed on the Keycloak server. When a realm is created, Keycloak automatically creates various roles that grant fine-grain permissions to access that new realm.
Admin users within the master realm can be granted management privileges to one or more other realms in the system. Each realm in Keycloak is represented by a client in the master realm. The name of the client is [realm name]-realm. These clients each have client-level roles defined which define varying level of access to manage an individual realm.
It is just an implementation detail; Notwithstanding, it makes it easier to conceptually think of the master realm as the top of the pyramid followed by its clients, in which are included the other realms as well. Furthermore, it also allows you to managed the realms from the point of view of the master realm, for instance:
Adding permissions in the form of roles to the other realms. Other approaches would likely be good as well, but the Keycloak developers opted for this one.
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.