By default, Keycloak provides the user id as sub(ject) in the OIDC ID token. But instead, I need the username as subject. I already tried the mentioned solutions for older, similar questions:
Using a script mapper (deprecated feature, not available in my environment / version 8.0.2 anymore)
Using a user attribute mapper (does not work)
Is there any other known solution?
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'm switching over from the legacy security subsystem to Elytron in WildFly 14.
A particular data source is using a legacy security domain with a custom login module. The custom login module is invoked with a username and an encoded password. The custom login module implements "org.picketbox.datasource.security.AbstractPasswordCredentialLoginModule" where decoded credentials are "returned" to the framework in the overridden commit method.
Since the legacy security subsystem is deprecated, I'd like to switch over to using Elytron and would like to implement similar credential handling. I searched around and found some discussions about creating an Elytron security domain that points to a custom security realm in which a class in a custom module would implement "org.wildfly.security.auth.server.SecurityRealm". I have yet to find any working examples and have been unable to figure this out.
Any ideas?
I have an application which uses LDAP authentication against AD, which works fine. However the UserDN and password for accessing LDAP are in clear text in the config files, and I would like to avoid clear text passwords.
In Softerra LDAP browser you have the option to authenticate with "Currently logged in user", does anyone know if this type of Windows Authentication is possible with Spring LDAP? Or is there perhaps another way to avoid credentials in config files (like using the credentials of the user trying to authenticate)?
With Microsoft SQL server, it is possible to do Windows Authentication via JDBC, since Microsoft provides some native code, has anyone heard about a similar functionality when using LDAP against AD?
"Currently logged in user"
this may mean that Kerberos based SASL authentication is used
You may check
https://docs.spring.io/spring-security-kerberos/docs/current/reference/htmlsingle/#ssk-kerberosldap
and
https://docs.spring.io/autorepo/docs/spring-security-kerberos/1.0.1.RELEASE/api/org/springframework/security/kerberos/client/ldap/KerberosLdapContextSource.html
The latter shows how the Kerberos ticket cache can be used.
Standalone CDO servers are configured using the cdo-server.xml configuration file, as explained on the CDO Wiki. A separate wiki page has further information about configuring server-side CDO/Net4j authentication, but it is outdated as of version 3.0, as noted on the page:
[...] Note that in CDO 3.0 we have an additional, superior athentication mechanism per CDOSession (not only on Net4j IConnector level). [...]
Neither new authentication mechanism, nor its usage are explained. How do I configure server-side authentication in CDO 3.0 or above?
The new authentication mechanism introduced in CDO 3.0 is configured using the userManager element in your cdo-server.xml, for example:
<repository name="MyRepo">
<userManager type="file" description="absolute-path-to-users-file"/>
...
</repository>
The above example is using the built-in FileUserManager, which has a factory registered with the type "file". This user manager implementation authenticates users against a list of usernames and passwords stored in a flat file at the location specified in the description attribute. This file should contain the users and their passwords in the following format:
user1:pwd1
user2:pwd2
Some background on implementing you own UserManager and how this configuration mechanism was implemented is available in the Eclipse Bugzilla issue Allow configuration of authentication in cdo-server.xml.
I've got pretty much the same question as: Jabber Openfire server v3.6.0a+ - how do I use Hybrid authentication?
But when I followed the instructions there, and I go into the Admin interface > Users and Groups > Create New User, I get the following message:
Not allowed: the user account system is read-only.
That tells me that the system is trying to add to the LDAP structure, and not to the database. Does anyone have a working config that allows both LDAP and Database users to login, and to be able to create Database Users?
I believe in the latest version of Openfire, settings are pulled from the database but not the openfire.xml file. Unfortunately, there's little documentation on their site.
OK... so I have been looking for how to do this for 6 months now. And not more than 15 mins after I post this question, I find the link here:
http://community.igniterealtime.org/message/204225
Also, the settings are now saved in the databsae, so the openfire.xml is irrelevant for these settings.