[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1151:
---------------------------------
PR 810: client side NameCallback
PR 848: server side AuthorizationCallback
> Empty authorization name for Digest mechanism causes authentication fail
> ------------------------------------------------------------------------
>
> Key: ELY-1151
> URL: https://issues.jboss.org/browse/ELY-1151
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta38
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta44
>
>
> SASL specification says about Authorization Identity String [1]:
> {quote}
> If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.*
> {quote}
> In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string.
> It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name.
> It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail.
> The same issue can occurs for every supported SASL mechanism. In needs to be revisited.
> We request blocker flag since current behavior violates SASL specification.
> [1] https://tools.ietf.org/html/rfc4422#section-3.4.1
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-8459) @TransactionAttribute should not be inherited per EJB 3.2 spec
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8459?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8459:
-----------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1442955|https://bugzilla.redhat.com/show_bug.cgi?id=1442955] from POST to MODIFIED
> @TransactionAttribute should not be inherited per EJB 3.2 spec
> ---------------------------------------------------------------
>
> Key: WFLY-8459
> URL: https://issues.jboss.org/browse/WFLY-8459
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: JBoss EA P7.0.x
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 11.0.0.Beta1
>
>
> It appears that JBoss EAP behaves as the *@TransactionAttribute* attribute was inherited.
> For example if I have a bean A that
> {noformat}
> @Stateless
> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
> public class ABean extends Base{
>
> public void foo(){ . . .}
> }
> {noformat}
> and a supper class
> {noformat}
> @TransactionAttribute(TransactionAttributeType.SUPPORTS)
> public class Base {
>
> @TransactionAttribute(TransactionAttributeType.NEVER)
> public void foo(){ . . }
> public void bar(){ . . .}
> }
> {noformat}
> and if I call each method
> {noformat}
> beanA.bar();
> beanA.foo();
> {noformat}
> I would expect to see *bar()* without an active transaction and *foo()* with an active transaction
> but what I see is that both method have no active transaction. This seems like spec violation since the *@TransactionAttribute* are not supposed to be inherited.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (ELY-1117) Regresion in DR17, elytron returns 401 instead of 500.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1117?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reopened ELY-1117:
-----------------------------
Reopening: requested {{required}} attribute to make keytab/principal check optional and disabled ({{required=false}}) by default
> Regresion in DR17, elytron returns 401 instead of 500.
> ------------------------------------------------------
>
> Key: ELY-1117
> URL: https://issues.jboss.org/browse/ELY-1117
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.1.0.Beta47
>
>
> There is regression against DR16. When Elytron kerberos security factory is misconfigured - wrong principal name - 401 is returned. Till DR16 it was 500.
> IMO 500 is more appropriate in this case as server is misconfigured and authenticatoin is not possible at all.
> But 401 means user can try authenticate with another credential. Also there is no other authentication mechanism configured, which could be tried to authenticate - just SPNEGO.
> {code:title=server.log}
> 09:26:33,615 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='localhost.localdomain' protocol='http'
> 09:26:33,616 TRACE [org.wildfly.security] (default task-1) Evaluating SPNEGO request: cached GSSContext = null
> 09:26:33,617 TRACE [org.wildfly.security] (default task-1) Obtaining GSSCredential for the service from callback handler...
> 09:26:33,617 TRACE [org.wildfly.security] (default task-1) No valid cached credential, obtaining new one...
> 09:26:33,618 TRACE [org.wildfly.security] (default task-1) Logging in using LoginContext and subject [Subject:
> ]
> 09:26:33,623 INFO [stdout] (default task-1) Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator false KeyTab is /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.3649597682700651441.keytab refreshKrb5Config is false principal is WRONG_SERVICE/wrong.host tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> 09:26:33,626 INFO [stdout] (default task-1) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb5-3763796955751468261.conf
> 09:26:33,626 INFO [stdout] (default task-1) Loaded from Java config
> 09:26:33,627 INFO [stdout] (default task-1) principal is WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> 09:26:33,628 INFO [stdout] (default task-1) Will use keytab
> 09:26:33,628 INFO [stdout] (default task-1) Commit Succeeded
> 09:26:33,628 INFO [stdout] (default task-1)
> 09:26:33,628 TRACE [org.wildfly.security] (default task-1) Logging in using LoginContext and subject [Subject:
> Principal: WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> Private Credential: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.3649597682700651441.keytab for WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> ] succeed
> 09:26:33,630 TRACE [org.wildfly.security] (default task-1) Creating GSSName for Principal 'WRONG_SERVICE/wrong.host(a)JBOSS.ORG'
> 09:26:33,634 INFO [stdout] (default task-1) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.3649597682700651441.keytab for WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> 09:26:33,635 INFO [stdout] (default task-1) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap71/target/krb/krb.3649597682700651441.keytab for WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> 09:26:33,635 TRACE [org.wildfly.security] (default task-1) Obtained GSSCredentialCredential [org.wildfly.security.credential.GSSKerberosCredential@1f]
> 09:26:33,636 TRACE [org.wildfly.security] (default task-1) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 09:26:33,637 TRACE [org.wildfly.security] (default task-1) Using SpnegoAuthenticationMechanism to authenticate WRONG_SERVICE/wrong.host(a)JBOSS.ORG using the following mechanisms: [[Lorg.ietf.jgss.Oid;@3409081b]
> 09:26:33,637 TRACE [org.wildfly.security] (default task-1) Caching GSSContext sun.security.jgss.GSSContextImpl@480e78a0
> 09:26:33,637 TRACE [org.wildfly.security] (default task-1) Caching KerberosTicket null
> 09:26:33,637 TRACE [org.wildfly.security] (default task-1) Sent HTTP authorizations: [null]
> 09:26:33,637 TRACE [org.wildfly.security] (default task-1) Request lacks valid authentication credentials
> 09:26:33,666 WARN [org.apache.http.impl.auth.HttpAuthenticator] (main) NEGOTIATE authentication error: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt))
> 09:26:33,667 TRACE [org.wildfly.security] (default task-2) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='localhost.localdomain' protocol='http'
> 09:26:33,667 TRACE [org.wildfly.security] (default task-2) Evaluating SPNEGO request: cached GSSContext = null
> 09:26:33,667 TRACE [org.wildfly.security] (default task-2) Obtaining GSSCredential for the service from callback handler...
> 09:26:33,668 TRACE [org.wildfly.security] (default task-2) Used cached GSSCredential [[GSSCredential:
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.2.840.113554.1.2.2 Accept [class sun.security.jgss.krb5.Krb5AcceptCredential]
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.3.6.1.5.5.2 Accept [class sun.security.jgss.spnego.SpNegoCredElement]]]
> 09:26:33,668 TRACE [org.wildfly.security] (default task-2) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 09:26:33,668 TRACE [org.wildfly.security] (default task-2) Using SpnegoAuthenticationMechanism to authenticate WRONG_SERVICE/wrong.host(a)JBOSS.ORG using the following mechanisms: [[Lorg.ietf.jgss.Oid;@b065a6e]
> 09:26:33,668 TRACE [org.wildfly.security] (default task-2) Caching GSSContext sun.security.jgss.GSSContextImpl@5c1a57e
> 09:26:33,669 TRACE [org.wildfly.security] (default task-2) Caching KerberosTicket null
> 09:26:33,669 TRACE [org.wildfly.security] (default task-2) Sent HTTP authorizations: [null]
> 09:26:33,669 TRACE [org.wildfly.security] (default task-2) Request lacks valid authentication credentials
> Debug is true storeKey false useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> [Krb5LoginModule] user entered username: jdukef95f0ce7-ed0b-4086-b498-e11f0cbee025
> principal is jdukef95f0ce7-ed0b-4086-b498-e11f0cbee025(a)JBOSS.ORG
> Commit Succeeded
> 09:26:33,691 TRACE [org.wildfly.security] (default task-3) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='localhost.localdomain' protocol='http'
> 09:26:33,691 TRACE [org.wildfly.security] (default task-3) Evaluating SPNEGO request: cached GSSContext = null
> 09:26:33,691 TRACE [org.wildfly.security] (default task-3) Obtaining GSSCredential for the service from callback handler...
> 09:26:33,691 TRACE [org.wildfly.security] (default task-3) Used cached GSSCredential [[GSSCredential:
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.2.840.113554.1.2.2 Accept [class sun.security.jgss.krb5.Krb5AcceptCredential]
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.3.6.1.5.5.2 Accept [class sun.security.jgss.spnego.SpNegoCredElement]]]
> 09:26:33,691 TRACE [org.wildfly.security] (default task-3) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 09:26:33,692 TRACE [org.wildfly.security] (default task-3) Using SpnegoAuthenticationMechanism to authenticate WRONG_SERVICE/wrong.host(a)JBOSS.ORG using the following mechanisms: [[Lorg.ietf.jgss.Oid;@ee77462]
> 09:26:33,692 TRACE [org.wildfly.security] (default task-3) Caching GSSContext sun.security.jgss.GSSContextImpl@209bce
> 09:26:33,692 TRACE [org.wildfly.security] (default task-3) Caching KerberosTicket null
> 09:26:33,692 TRACE [org.wildfly.security] (default task-3) Sent HTTP authorizations: [null]
> 09:26:33,692 TRACE [org.wildfly.security] (default task-3) Request lacks valid authentication credentials
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Handling MechanismInformationCallback type='HTTP' name='SPNEGO' host-name='localhost.localdomain' protocol='http'
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Evaluating SPNEGO request: cached GSSContext = null
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Obtaining GSSCredential for the service from callback handler...
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Used cached GSSCredential [[GSSCredential:
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.2.840.113554.1.2.2 Accept [class sun.security.jgss.krb5.Krb5AcceptCredential]
> WRONG_SERVICE/wrong.host(a)JBOSS.ORG 1.3.6.1.5.5.2 Accept [class sun.security.jgss.spnego.SpNegoCredElement]]]
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Using SpnegoAuthenticationMechanism to authenticate WRONG_SERVICE/wrong.host(a)JBOSS.ORG using the following mechanisms: [[Lorg.ietf.jgss.Oid;@511a63e2]
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Caching GSSContext sun.security.jgss.GSSContextImpl@5fdd87b1
> 09:26:33,757 TRACE [org.wildfly.security] (default task-4) Caching KerberosTicket null
> 09:26:33,759 TRACE [org.wildfly.security] (default task-4) Sent HTTP authorizations: [Negotiate YIIE1gYGKwYBBQUCoIIEyjCCBMagDTALBgkqhkiG9xIBAgKhBAMCAfaiggStBIIEqWCCBKUGCSqGSIb3EgECAgEAboIElDCCBJCgAwIBBaEDAgEOogcDBQAgAAAAo4IBKGGCASQwggEgoAMCAQWhCxsJSkJPU1MuT1JHoigwJqADAgEAoR8wHRsESFRUUBsVbG9jYWxob3N0LmxvY2FsZG9tYWluo4HhMIHeoAMCARGigdYEgdNZUz5w85v5Lg3rdGjYo4b+X5C6BpUMjg7SMoS+xl5ChgJMY0VQjvizbudYm0UXRRHgDXLE8rH1dx4VjK/yZ4W7GL4yP7wqrZLu9bqG+V6bNu0q5OijcV08XzwvE2EuL7SLhJ+3MtGsAclO/BkZwppYuMMJzFPN0nwguITxE8m+9Y/X+ikRtM2XsXINqduMFM5BfAZIcskA0yQ6ZqqB/gtDq6VGWKZ+KMr9fAMVfqH3DFE+Rwm4Ei6WMg2sJ9bAGpZgHOKjYhQDvMa49fxDth5tL8COpIIDTTCCA0mgAwIBEaKCA0AEggM82CoQag7UyA/xrAduZ14kwQUQiFvL0FNubJqi+r+hDtVd+ip549Veh7/XqskzaSQ/5+MJUhbx879YxkEUrUnnmnkQvtVxlZo7bhQMhhbuoJCA8aeBwOsBLd/DMvk9FxjP7axEfOSB2ENZ02mvEPqy8c039rGmWKpgimrJOjn9v3MkIV6dTtYVutdyW9o9cJGzT2+qOcOcylS19u2MNzIYH5XcpMWzGAX+ij7jNy/w7jHWnh7eXgl89et4L0zNVSsRmSNG6/95/zqvzAUpgmM6OyMTT2Zpd79vFAL/rI9bTsFCkGzB0pBFhcEuNmNiaLD3xKTLzsEpJqruue+7+FYmF9vOFTy1mFxMt5twkkGC48x8bPLFf2F8RAXKlrZp5HAD3MbmrTdCOzFW77yzFbCrCB1Fw0qtzLuWFZFJnMtZL4074WmOMR9upTNR6D76yhUJw8+HV5iPpJzxq84usRUI/jHkF7TdBJll0MpJQbXJMteYGAVp04jaisKsAQVPLfcmgEuamb9nrdTJ3E+zkviB80NhK2JwTZzsnGIudoPWaSl7eM7/XajgM/9MFwWkiB/z7iCtiXdrTLkJg0ZQeBlImNK6MO79NHaO6e5fG+jKEd7SuEa/MJmBRCpTjkc3g87N5wDMzz16wmzgRE96AoF9vS9hJaoM6CkPSigvno1x5A+e4e3+kOObY1QYzR5bJLwG+kzQGhKxkjI5CwS9M0rVkvxIU+BEIWgVCp8447EtXFmrsbREAwQ432kbTDdQLJZeUDjJFY9aoqVoUpePukD3H92icwvQkEvahm6U2q3bstLSKq47VRwtJr7q28PLllFlkFI7WPbsOgl5ZZ+SzvleskVPvNoX5I+HyQJHLO3cz/DGRpswGLxTmCSpRYe3Ul/33AE+sSnhqC9Ndl8e+z7uZgVaCMZci8JJ2/ZUfv72BDKou4BiFIo+G6IzFEFMs0O+x8fueJ/3aKoHSxV5WEANhW9W8mzpewf0wvYojlRL4zgAorVCamSIuG3OB4vq5OSlDEC9raRTR5Sl2EU+5WvDF2UzA6VDpkb58DGVm8FA7O5JFehY7ErEyD8gTM98i5FCK+kUORguAXK3fKVt]
> 09:26:33,759 TRACE [org.wildfly.security] (default task-4) Processing incoming response to a challenge...
> 09:26:33,764 INFO [stdout] (default task-4) Entered Krb5Context.acceptSecContext with state=STATE_NEW
> 09:26:33,768 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): JBOSS.ORG
> 09:26:33,768 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): HTTP
> 09:26:33,768 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): localhost.localdomain
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTab: load() entry length: 79; type: 16
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): JBOSS.ORG
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): HTTP
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): localhost.localdomain
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTab: load() entry length: 87; type: 18
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): JBOSS.ORG
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): HTTP
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): localhost.localdomain
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTab: load() entry length: 63; type: 3
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): JBOSS.ORG
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): HTTP
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): localhost.localdomain
> 09:26:33,769 INFO [stdout] (default task-4) >>> KeyTab: load() entry length: 71; type: 17
> 09:26:33,770 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): JBOSS.ORG
> 09:26:33,770 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): HTTP
> 09:26:33,770 INFO [stdout] (default task-4) >>> KeyTabInputStream, readName(): localhost.localdomain
> 09:26:33,770 INFO [stdout] (default task-4) >>> KeyTab: load() entry length: 71; type: 23
> 09:26:33,770 INFO [stdout] (default task-4) Looking for keys for: WRONG_SERVICE/wrong.host(a)JBOSS.ORG
> 09:26:33,816 TRACE [org.wildfly.security] (default task-4) GSSContext message exchange failed: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96)
> at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
> at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:556)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.lambda$evaluateRequest$2(SpnegoAuthenticationMechanism.java:164)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:164)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 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 org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 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:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> 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:211)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> 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: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:278)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149)
> at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
> at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (ELY-1208) Elytron dir-context ignores protocol, host and port options from Authentication Configuration
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1208?page=com.atlassian.jira.plugin.s... ]
Jan Kalina closed ELY-1208.
---------------------------
Resolution: Won't Fix
by discussion should be nacked as unsupported
> Elytron dir-context ignores protocol, host and port options from Authentication Configuration
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1208
> URL: https://issues.jboss.org/browse/ELY-1208
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> When Elytron {{dir-context}} uses {{authentication-context}} and obtains some authentication configuration from it then dir context ignores obtained protocol, host and port options from authentication configuration. Original {{dir-context.url}} is used without any change.
> It means some authentication client like following cannot be used with dir context:
> {code}
> <authentication-client>
> <authentication-configuration name="unsecureConfig" authentication-name="uid=admin,ou=system">
> <credential-reference clear-text="secret"/>
> </authentication-configuration>
> <authentication-configuration name="secureConfig" authentication-name="uid=admin,ou=system" protocol="ldaps" port="10636">
> <credential-reference clear-text="secret"/>
> </authentication-configuration>
> <authentication-context name="authCtx">
> <match-rule match-purpose="secure" authentication-configuration="secureConfig"/>
> <match-rule authentication-configuration="unsecureConfig"/>
> </authentication-context>
> </authentication-client>
> ...
> <dir-contexts>
> <dir-context name="dir-context" url="ldap://127.0.0.1:10389" authentication-context="authCtx"/>
> </dir-contexts>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (ELY-1208) Elytron dir-context ignores protocol, host and port options from Authentication Configuration
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1208?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1208:
-------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Elytron dir-context ignores protocol, host and port options from Authentication Configuration
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1208
> URL: https://issues.jboss.org/browse/ELY-1208
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> When Elytron {{dir-context}} uses {{authentication-context}} and obtains some authentication configuration from it then dir context ignores obtained protocol, host and port options from authentication configuration. Original {{dir-context.url}} is used without any change.
> It means some authentication client like following cannot be used with dir context:
> {code}
> <authentication-client>
> <authentication-configuration name="unsecureConfig" authentication-name="uid=admin,ou=system">
> <credential-reference clear-text="secret"/>
> </authentication-configuration>
> <authentication-configuration name="secureConfig" authentication-name="uid=admin,ou=system" protocol="ldaps" port="10636">
> <credential-reference clear-text="secret"/>
> </authentication-configuration>
> <authentication-context name="authCtx">
> <match-rule match-purpose="secure" authentication-configuration="secureConfig"/>
> <match-rule authentication-configuration="unsecureConfig"/>
> </authentication-context>
> </authentication-client>
> ...
> <dir-contexts>
> <dir-context name="dir-context" url="ldap://127.0.0.1:10389" authentication-context="authCtx"/>
> </dir-contexts>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-1192?page=com.atlassian.jira.plugin.s... ]
Ondrej Lukas updated ELY-1192:
------------------------------
Description:
In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process.
This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers).
This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain.
[1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page...
was:
In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process.
This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers).
[1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page...
> HTTP status 500 when no principal is returned by aggregate-principal-transformer
> --------------------------------------------------------------------------------
>
> Key: ELY-1192
> URL: https://issues.jboss.org/browse/ELY-1192
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta42
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process.
> This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers).
> This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain.
> [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months