[JBoss JIRA] (ELY-1191) Undertow CLIENT_CERT via Elytron and HTTP/2 does not work
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1191?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1191:
----------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> Undertow CLIENT_CERT via Elytron and HTTP/2 does not work
> ---------------------------------------------------------
>
> Key: ELY-1191
> URL: https://issues.jboss.org/browse/ELY-1191
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 1.1.0.Beta49
>
>
> When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content.
> I can see following TRACE messages in server.log:
> {code}
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client])
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser]
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client.
> 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => []
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed
> 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client]
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https'
> 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session
> {code}
> Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}.
> When I disable 'http2' in https-listener:
> {code}
> /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
> reload
> {code}
> I can now access secured content as expected. Also trace log contains different (more healthy) messages now.
> This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library.
> As described in JBEAP-9803, Undertow needs to write into ssl-context when HTTP/2 with ALPN is utilized. Maybe this might be the source of this problem?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-1190) Capture Subject into AuthenticationConfiguration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1190?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1190:
----------------------------------
Fix Version/s: 1.1.0.Beta49
(was: 1.1.0.Beta48)
> Capture Subject into AuthenticationConfiguration
> ------------------------------------------------
>
> Key: ELY-1190
> URL: https://issues.jboss.org/browse/ELY-1190
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Authentication Client, SASL
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta49
>
>
> When an AuthenticationConfiguration is captured, it represents the identity being authenticated. Some mechanisms require a Subject to be established in order to retrieve the identity and credentials to use. The combination of these two facts implies that the AuthenticationConfiguration must encapsulate the Subject that was present at the time the configuration is realized by the ACCC. This Subject in turn must be propagated to the SASL authentication client (and later, possibly SSLContext to support KRB mechanisms).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item
by Michal Petrov (JIRA)
Michal Petrov created WFCORE-2885:
-------------------------------------
Summary: list-remove operation succeeds when removing non-existent item
Key: WFCORE-2885
URL: https://issues.jboss.org/browse/WFCORE-2885
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Michal Petrov
Assignee: Michal Petrov
When removing an item from a list the operation should fail if the item doesn't exist. E.g.
{code}
/subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC")
{code}
the operation already fails when using an invalid index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8858) Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer
by Scott Marlow (JIRA)
Scott Marlow created WFLY-8858:
----------------------------------
Summary: Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer
Key: WFLY-8858
URL: https://issues.jboss.org/browse/WFLY-8858
Project: WildFly
Issue Type: Task
Components: JPA / Hibernate
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 12.0.0.Alpha1
Applications can instead use the jboss.as.jpa.classtransformer property to control whether the application can use entity class rewriting. Starting with Hibernate ORM 5.0+, Hibernate defaults to always rewrite entity classes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months