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?
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've been trying to set up a quarkus server to validate tokens from Azure Active Directory with quarkus-oidc. I noticed that under the hood quarkus-oidc uses vert.x oauth2 implementation, which has support for Azure Active Directory amongst other providers but unfortunately there seems to be no way to configure quarkus-oidc. The keycloak provider seems to be hardcoded in the class OidcRecorder. Is there a way to bypass it? replace it? or configure it properly?
So i am trying to add claims to a service provider in Wso2. I have managed to create an IdentityApplication and connect it with some SSO configuration. The only problem is adding Claims to that SSO because i use those after the SSO login.
So what i have tried so far:
I have added an SSO configuration using the addRPServiceProvider soap function from the IdentitySAMLSSOConfigService
I have created a service provider using createApplication soap function from the IdentityApplicationManagementService and connected it to the SSO configuration i added earlier
At this point my external application connects correctly with Wso2 and do the SSO. The only thing i need is to return additional claim info with the SSO response.
I am trying to do that using the claimConfig part of the createApplication function parameters but i cant seem to make it right.
Is there somewhere some more info about how to set this up through the AdminServices? ( the official docs are not really helping
)
Please refer this documentation for more information on using the API. You can't add the claimConfig during the createApplication call as it only allows you to set the applicationName and description. Set the claimConfig during updateApplication method. The document has a sample request in Claim configuration level parameters section.
I have configured OpenAM with the DesktopSSO module and everything is working fine with our SAML 2.0 app for domain computers. When they request the app, it redirects to OpenAM and they are immediately authenticated. I am trying to understand what config is needed in OpenAM to support non domain PC's. Is there an option in OpenAM to say 'if the device does not support this module, use another module' ?
It sounds like you are wanting to default to another authentication module if the DesktopSSO module is unavailable. You can do this by configuring another authentication module such as possibly an AD module and add the second module to the Authentication Chain. Set the Criteria to SUFFICIENT for both modules in the chain and in the options include the following string iplanet-am-auth-shared-state-enabled=true for both modules.
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.