Hi,
On Mon, Apr 20, 2015 at 3:19 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Mon, Apr 20, 2015 at 3:05 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com> wrote:
>>> For JBoss (EAP/WildFly) such mapping file is not needed, but there a
>>> (dummy) security domain has to be added, which is again a *really*
>>> unfortunate thing and a big impediment for usability.
>>
>> Let me know if you want me to look into this for WildFly - I am in the
>> process of re-working the security layer for WildFly 10 anyway so this may
>> be something I can visit early.
I just hacked together something using an UndertowHandlerExtension.
It's arguably even more hackier than the dummy domain, but it can be
used from within the application and doesn't require fiddling with
standalone.xml:
It's the following code put into the mentioned UndertowHandlerExtension:
String securityDomain = "other";
IdentityManager identityManager = deploymentInfo.getIdentityManager();
if (identityManager instanceof JAASIdentityManagerImpl) {
try {
Field securityDomainContextField =
JAASIdentityManagerImpl.class.getDeclaredField("securityDomainContext");
securityDomainContextField.setAccessible(true);
SecurityDomainContext securityDomainContext =
(SecurityDomainContext)
securityDomainContextField.get(identityManager);
securityDomain =
securityDomainContext.getAuthenticationManager().getSecurityDomain();
} catch (NoSuchFieldException | SecurityException |
IllegalArgumentException | IllegalAccessException e) {
throw new RuntimeException(e);
}
}
ApplicationPolicy applicationPolicy = new
ApplicationPolicy(securityDomain);
JASPIAuthenticationInfo authenticationInfo = new
JASPIAuthenticationInfo(securityDomain);
applicationPolicy.setAuthenticationInfo(authenticationInfo);
SecurityConfiguration.addApplicationPolicy(applicationPolicy);
deploymentInfo.setJaspiAuthenticationMechanism(new
JASPIAuthenticationMechanism(securityDomain, null));
deploymentInfo.setSecurityContextFactory(new
JASPICSecurityContextFactory(securityDomain));
I did some quick tests and it seems to work, but something like this
should of course be replaced by a real solution.
Kind regards,
Arjan Tijms
>
> Cool, I discussed this before with your colleague Stefan Guilhen, who
> did most of the initial integration. To activate JASPIC so that auth
> modules can be set programmatically the following dummy domain needs
> to be added to standalone.xml:
>
> <security-domain name="jaspitest" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
>
> And then referenced of course in jboss-web.xml.
>
> This is however a hack of course. If I'm not mistaken because of the
> new config changes that were to be expected for Elytron, Stefan did
> not yet get around to getting rid of the necessity of the dummy
> domain.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>>
>>
>>
>>> On WebLogic this unfortunately doesn't work at all, since there CDI is
>>> initialized too late and thus not available to the auth mechanism.
>>>
>>> So there are still a few small (but very important!) hurdles to
>>> address to make this really user friendly and portable on all servers,
>>> but I think this is a nice start ;)
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> cheers,
>>>>
>>>> adam
>>>>
>>>> I broke my underarm, so my coding speed suffers a bit, but next week
>>>> should be back to normal.
>>
>>