[JBoss JIRA] (ELY-1332) NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1332?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1332:
----------------------------------
Fix Version/s: (was: 1.8.0.CR1)
> NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload
> --------------------------------------------------------------------------------
>
> Key: ELY-1332
> URL: https://issues.jboss.org/browse/ELY-1332
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Priority: Major
>
> When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured".
> The server.log contains:
> {noformat}
> 08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224)
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190)
> ... 7 more
> Caused by: java.security.ProviderException: Secmod module already configured
> at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276)
> at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107)
> ... 12 more
> ..
> 08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("provider-loader" => "nss")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException
> Caused by: java.lang.reflect.InvocationTargetException
> Caused by: java.security.ProviderException: Secmod module already configured"}}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ELY-1519) Make restore of SecurityIdentity on replicated session configurable
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1519?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1519:
----------------------------------
Fix Version/s: 1.8.0.CR1
> Make restore of SecurityIdentity on replicated session configurable
> -------------------------------------------------------------------
>
> Key: ELY-1519
> URL: https://issues.jboss.org/browse/ELY-1519
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Final
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Priority: Major
> Fix For: 1.8.0.CR1
>
>
> Currently in clustered environment Security Identity is restored during
> * failover
> * load balancer change node (not sticky behaviour)
> * session passivation/activation
> This is mainly expected and good. It ensures performance gain because no additional SPNEGO negotiation is performed. But it can make troubles for kerberos ticket propagation, as kerberos ticket can't be serialized and restored.
> So idea is to have flag to turn this default behaviour off. When user authenticate to app1 on serverA and then wants to access app1 on serverB, SPNEGO authentication will be activated and kerberos ticket will be negotiated and will be available on serverB as well.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ELY-1675) Merge roles from entry and entry attributes
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1675?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1675:
----------------------------------
Fix Version/s: (was: 1.8.0.CR1)
> Merge roles from entry and entry attributes
> -------------------------------------------
>
> Key: ELY-1675
> URL: https://issues.jboss.org/browse/ELY-1675
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Critical
>
> Double check Elytron ldap realm is capable doing this:
> Having ldap entries like this
> {code}
> dn: cn=jduke,ou=Roles,ou=example2,${dnSuffix}
> objectClass: top
> objectClass: organizationalRole
> description: cn=Echo,ou=Roles,ou=example2,${dnSuffix}
> description: cn=TheDuke,ou=Roles,ou=example2,${dnSuffix}
> cn: jduke
> {code}
> User will have roles jduke, Echo and TheDuke.
> This was possible with Picketbox with this configuration
> {code}
> EapSetupTask roleAttributesConfiguration =
> new LdapExtSecurityDomainBuilder(SECURITY_DOMAIN_NAME_PREFIX + DEP2)
> .prepareDefaultForLdapServer(ldapServer)
> .baseCtxDN("ou=People,ou=example2," + ldapServer.getDNSuffix())
> .rolesCtxDN("ou=Roles,ou=example2," + ldapServer.getDNSuffix())
> .referral("ignore")
> .roleFilter("(|(objectClass=referral)(cn={0}))")
> .roleAttributeID("description")
> .roleAttributeIsDN("true")
> .roleNameAttributeID("cn")
> .roleRecursion("0")
> .configure();
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ELY-1668) LDAP searchScope=OBJECT_SCOPE Elytron alternative
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1668?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1668:
----------------------------------
Fix Version/s: (was: 1.8.0.CR1)
> LDAP searchScope=OBJECT_SCOPE Elytron alternative
> -------------------------------------------------
>
> Key: ELY-1668
> URL: https://issues.jboss.org/browse/ELY-1668
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Critical
>
> During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron.
> "As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope.
> Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of.
> {code}
> dn: ou=People,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,${dnSuffix}
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: RolesLevel1
> dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: groupOfNames
> cn: RoleUnderLevel1
> member: uid=jduke,ou=People,${dnSuffix}
> description: the RoleUnderLevel1 group
> {code}
> [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ELY-1455) DB query seen for each request using programatic authentication
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1455:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> DB query seen for each request using programatic authentication
> ----------------------------------------------------------------
>
> Key: ELY-1455
> URL: https://issues.jboss.org/browse/ELY-1455
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Affects Versions: 1.2.0.Beta10
> Reporter: Martin Choma
> Priority: Critical
> Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request.
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
> <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
> <attribute-mapping>
> <attribute to="Roles" index="1"/>
> </attribute-mapping>
> <simple-digest-mapper password-index="2"/>
> </principal-query>
> </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto(a)myapp.com], pre-realm rewritten: [alberto(a)myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto(a)myapp.com], realm rewritten: [alberto(a)myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto(a)myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto(a)myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto(a)myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto(a)myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months