[JBoss JIRA] (WFLY-7295) Internal server error is returned for Elytron authentication when LDAP server is unreachable
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7295:
----------------------------------
Summary: Internal server error is returned for Elytron authentication when LDAP server is unreachable
Key: WFLY-7295
URL: https://issues.jboss.org/browse/WFLY-7295
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Critical
In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
Exception in server log:
{code}
ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
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:745)
Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
... 45 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
... 67 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7294) Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7294:
----------------------------------
Summary: Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
Key: WFLY-7294
URL: https://issues.jboss.org/browse/WFLY-7294
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
Deployment fails with following exception in server log:
{code}
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
... 6 more
Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
at java.lang.Iterable.forEach(Iterable.java:75)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
... 8 more
ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7294) Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7294?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7294:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Deployment fails when unreachable LDAP is used for Elytron LDAP authentication
> ------------------------------------------------------------------------------
>
> Key: WFLY-7294
> URL: https://issues.jboss.org/browse/WFLY-7294
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> In case when LDAP server used by Elytron dir-context is unreachable (e.g. LDAP is down or some network failures occur) or when dir-context is incorrectly set (e.g. used password is wrong) then application which uses this dir-context cannot be deployed. Deployment fails and confusing exception occurs in server log.
> We request blocker since it causes that deployments (which have already been successfully deployed) can unexpectedly fail when server is restarted/reloaded in time when LDAP server is unreachable.
> Deployment fails with following exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:349)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:346)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:294)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:402)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:206)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:171)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:234)
> ... 8 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "print-roles.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./print-roles" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./print-roles"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password Credentials Callback
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-658:
---------------------------
Description:
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.
This should also allow Elytron to support other grant types defined by OAuth2 in the future.
Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html
was:
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with grant type.
This should also allow Elytron to support other grant types defined by OAuth2 in the future.
Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html
> OAuth2 Resource Owner Password Credentials Callback
> ---------------------------------------------------
>
> Key: ELY-658
> URL: https://issues.jboss.org/browse/ELY-658
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Callbacks
> Affects Versions: 1.1.0.Beta10
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type.
> This should also allow Elytron to support other grant types defined by OAuth2 in the future.
> Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
> In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
> [1] https://tools.ietf.org/html/rfc6749#page-9
> [2] https://openid.net/specs/openid-connect-discovery-1_0.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password Credentials Callback
by Pedro Igor (JIRA)
Pedro Igor created ELY-658:
------------------------------
Summary: OAuth2 Resource Owner Password Credentials Callback
Key: ELY-658
URL: https://issues.jboss.org/browse/ELY-658
Project: WildFly Elytron
Issue Type: Feature Request
Components: Callbacks
Affects Versions: 1.1.0.Beta10
Reporter: Pedro Igor
Assignee: Pedro Igor
We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with grant type.
This should also allow Elytron to support other grant types defined by OAuth2 in the future.
Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2].
In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol.
[1] https://tools.ietf.org/html/rfc6749#page-9
[2] https://openid.net/specs/openid-connect-discovery-1_0.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-627:
--------------------------------
IBM values: we dont need to support SSL_TLS + SSL_TLSv2, as it is only shortcut to select more protocols which we already support.
I will add the mapping from standard text names (like "TLSv1.2") to enum values.
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7278) Unable to add trust-manager with ldap-key-store (classloading)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7278:
----------------------------------
Also would be better to not require to have a LDAP server online to create the resource - LDAP should be contacted when required - this behavior would solve this issue too probably.
> Unable to add trust-manager with ldap-key-store (classloading)
> --------------------------------------------------------------
>
> Key: WFLY-7278
> URL: https://issues.jboss.org/browse/WFLY-7278
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails:
> {code:java}
> Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120)
> ... 16 more
> java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113)
> ... 28 more
> {code}
> Direct key-store aliases listing using works ok:
> {code:java}
> /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-657) Wrong error message in OAuth2Client
by David Lloyd (JIRA)
David Lloyd created ELY-657:
-------------------------------
Summary: Wrong error message in OAuth2Client
Key: ELY-657
URL: https://issues.jboss.org/browse/ELY-657
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Mechanisms
Reporter: David Lloyd
Priority: Minor
In OAuth2Client, if the bearer token callback is unsupported, an {{mechCallbackHandlerDoesNotSupportUserName}} is generated. There should be an error that is more specific to the token callback.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months