January 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Farah Juma updated ELY-816: --------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.8.0.CR2 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1409: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Update HTTP authentication mechanism API to support re-use of response handlers > ------------------------------------------------------------------------------- > > Key: ELY-1409 > URL: https://issues.jboss.org/browse/ELY-1409 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.8.0.CR2 > > > At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request. > Making the scopes available should allow for state to be transferred on the request scope. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

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.8.0.CR2 (was: 1.8.0.CR1) > 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.8.0.CR2 > > > 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.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1464) Programatic authentication should be caching the SecurityIdentity not the name of the identity

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1464?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1464: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Programatic authentication should be caching the SecurityIdentity not the name of the identity > ---------------------------------------------------------------------------------------------- > > Key: ELY-1464 > URL: https://issues.jboss.org/browse/ELY-1464 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.8.0.CR2 > > > By only caching the name of the identity the server authentication context -> security domain -> security realm chain is called for each subsequent request when we should have been able to re-use an existing identity. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1519) Make restore of SecurityIdentity on replicated session configurable

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1519?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1519: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 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.CR2 > > > 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)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1525: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > When SSO is enabled, multipart form and form enconding stop working. > -------------------------------------------------------------------- > > Key: ELY-1525 > URL: https://issues.jboss.org/browse/ELY-1525 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.6.Final, 1.2.1.Final > Reporter: Estevão Freitas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.8.0.CR2 > > > I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ". > I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On . > When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working. > If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1617) Support SSL Certificate revocation using OCSP

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1617?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1617: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: ELY-1617 > URL: https://issues.jboss.org/browse/ELY-1617 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Affects Versions: 1.4.0.Final > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 1.8.0.CR2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1677: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Elytron Bearer Token Authentication - Return a 401 on Invalid Token > ------------------------------------------------------------------- > > Key: ELY-1677 > URL: https://issues.jboss.org/browse/ELY-1677 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Mechanisms > Affects Versions: 1.7.0.CR1 > Reporter: Edward Stathopoulos > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.8.0.CR2 > > > *Issue* > Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...]. > It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question? > This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token. > {quote} > And in response to a protected resource request with an > authentication attempt using an expired access token: > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Bearer realm="example", > error="invalid_token", > error_description="The access token expired" > {quote} > *Potential Solution* > Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source. > {code} > if (verifyCallback.isVerified()) { > AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null); > handleCallback(authorizeCallback); > if (authorizeCallback.isAuthorized()) { > httpBearer.debugf("Token authentication successful."); > handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true)); > handleCallback(AuthenticationCompleteCallback.SUCCEEDED); > request.authenticationComplete(); > return; > } > else{ > httpBearer.debugf("Token authorization failed message."); > request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN)); > return; > } > } > httpBearer.debugf("Token authentication failed."); > request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED)); > return; > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

[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.8.0.CR2 (was: 1.8.0.CR1) > 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.8.0.CR2 > > 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.12.1#712002)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1689) Rewrite HttpAuthenticator$AuthenticationExchange.authenticate() to use a recursive call.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1689?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1689: ---------------------------- Fix Version/s: 1.8.0.CR2 (was: 1.8.0.CR1) > Rewrite HttpAuthenticator$AuthenticationExchange.authenticate() to use a recursive call. > ---------------------------------------------------------------------------------------- > > Key: ELY-1689 > URL: https://issues.jboss.org/browse/ELY-1689 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.8.0.CR2 > > > By switching to a recursive call we can eliminate the intermediate ArrayList which is required to hold the responders. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2019