December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1682: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.jboss.org/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.11.0.CR4 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1440?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1440: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.jboss.org/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR4 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Farah Juma updated ELY-533: --------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR4 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1842) Update the tool to support generating and exporting / importing a secret key to the credential store

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1842?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1842: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Update the tool to support generating and exporting / importing a secret key to the credential store > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1842 > URL: https://issues.jboss.org/browse/ELY-1842 > Project: WildFly Elytron > Issue Type: Requirement > Components: Command-Line Tool, Credential Store > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR4 > > > In general the following options should be supported: - > * `--generate-secret-key` > * `--export-secret-key` > * `--import-secret-key` -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1809) Update JAPICMP on a module by module basis

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1809?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1809: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Update JAPICMP on a module by module basis > ------------------------------------------ > > Key: ELY-1809 > URL: https://issues.jboss.org/browse/ELY-1809 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR4 > > > Each module should test it's own compatibility - however the compatible version should likely be defined in the root pom. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1808) Undertake further review of all duplicate packages to ensure we can make unique

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1808?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1808: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Undertake further review of all duplicate packages to ensure we can make unique > ------------------------------------------------------------------------------- > > Key: ELY-1808 > URL: https://issues.jboss.org/browse/ELY-1808 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.11.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1778?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1778: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.jboss.org/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.11.0.CR4 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1765?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1765: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.jboss.org/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.11.0.CR4 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1749) Code review of WildFlyElytronProvider

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1749?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1749: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > Code review of WildFlyElytronProvider > ------------------------------------- > > Key: ELY-1749 > URL: https://issues.jboss.org/browse/ELY-1749 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1745?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1745: ---------------------------- Fix Version/s: 1.11.0.CR4 (was: 1.11.0.CR3) > The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1745 > URL: https://issues.jboss.org/browse/ELY-1745 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR4 > > > The NPE is due to the following code: - > {noformat} > } else if (callback instanceof AvailableRealmsCallback) { > Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames(); > if (log.isTraceEnabled()) { > log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names)); > } > if (! names.isEmpty()) { > ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()])); > } > handleOne(callbacks, idx + 1); > {noformat} > If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2019