March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11781) Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11781?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-11781: --------------------------------------- Assignee: (was: Darran Lofthouse) > Need to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-11781 > URL: https://issues.jboss.org/browse/WFLY-11781 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 15.0.1.Final > Reporter: indrajit ingawale > Priority: Major > > It is requirement to use principal-transformer in aggregate-realm in between authentication-realm and authorization-realm . > -------------------------------------- > <security-domain name="TestDomain" default-realm="TestAggRealm" permission-mapper="default-permission-mapper" pre-realm-principal-transformer="test-transformer" security-event-listener="local-audit"> > <realm name="TestAggRealm" role-decoder="from-roles-attribute"/> > </security-domain> > . > . > <aggregate-realm name="TestAggRealm" authentication-realm="TestLdapRealm" authorization-realm="Test_Auth_LdapRealm"/> > -------------------------------------- > I think to achieve this there need to be something like "mid-realm-principal-transformer" in <aggregate-realm> only . -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6371) LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-6371?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-6371: -------------------------------------- Assignee: (was: Darran Lofthouse) > LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-6371 > URL: https://issues.jboss.org/browse/WFLY-6371 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Bartosz Baranowski > Priority: Major > > In case when LdapExtLoginModule is correctly configured for authentication, but its attributes rolesCtxDN and roleFilter are not set, then authentication with correct username and password leads to FailedLoginException. > Expected behavior is that user should be authenticated but no roles should be assigned to them. > Possible EAP configuration: > <security-domain name="ldap"> > <authentication> > <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required"> > <module-option name="baseFilter" value="(uid= > {0})"/> > <module-option name="bindDN" value="uid=admin,ou=system"/> > <module-option name="baseCtxDN" value="ou=People,o=MyOrg,o=primary,dc=jboss,dc=org"/> > <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/> > <module-option name="java.naming.security.authentication" value="simple"/> > <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/> > <module-option name="bindCredential" value="secret"/> > </login-module> > </authentication> > </security-domain> > In case when these attributes are added > <module-option name="rolesCtxDN" value="ou=Roles,o=MyOrg,o=primary,dc=jboss,dc=org"/> > <module-option name="roleFilter" value="(member={0} > )"/> > then user is correctly authenticated (even in case when no role is assigned to them). > It is caused by internal NPE thrown from method rolesSearch in LdapExtLoginModule class on line: > results = ldapCtx.search(rolesCtxDN, roleFilter, filterArgs, constraints); > DEBUG [org.jboss.security] (default task-2) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required > at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) > at javax.security.auth.login.LoginContext.login(LoginContext.java:595) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:350) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:338) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:148) > at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111) > at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:82) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106) > 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:51) > 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:56) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3592) Investigate: Undo/Redo regression on right panel

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-3592?page=com.atlassian.jira.plugi... ] Klara Kufova updated DROOLS-3592: --------------------------------- Summary: Investigate: Undo/Redo regression on right panel (was: Undo/Redo regression on right panel) > Investigate: Undo/Redo regression on right panel > ------------------------------------------------ > > Key: DROOLS-3592 > URL: https://issues.jboss.org/browse/DROOLS-3592 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > After naming/renaming of header, undo/redo does not restore correctly the right panel status. > Start this ticket after merging of DROOLS-3242, DROOLS-3357, DROOLS-3466, DROOLS-3485, DROOLS-3568 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11131) @LoginToContinue.errorPage doesn't work for pages in WEB-INF (New Java EE 8 Security)

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11131?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-11131: --------------------------------------- Assignee: (was: Darran Lofthouse) > @LoginToContinue.errorPage doesn't work for pages in WEB-INF (New Java EE 8 Security) > ------------------------------------------------------------------------------------- > > Key: WFLY-11131 > URL: https://issues.jboss.org/browse/WFLY-11131 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.1.Final > Reporter: Instantiation Exception > Priority: Major > > I have this configuration: > {code:java} > @FormAuthenticationMechanismDefinition( > loginToContinue = @LoginToContinue( > loginPage = "/WEB-INF/account/login.xhtml", > errorPage = "/WEB-INF/account/login.xhtml?error=true")) > @ApplicationScoped > public class SecurityConfiguration {} > {code} > When I open browser and go to restricted page, I am forwarded to login page. Then I input invalid username and password and submit form (action="j_security_check"). My browser sends me redirect to http://localhost:8080/WEB-INF/account/login.xhtml?error=true. I believe it should forward request to /WEB-INF/account/login.xhtml?error=true because standard FORM login-config in web.xml worked this way. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11130) javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11130?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-11130: --------------------------------------- Assignee: (was: Darran Lofthouse) > javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security) > ------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-11130 > URL: https://issues.jboss.org/browse/WFLY-11130 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.1.Final > Reporter: Instantiation Exception > Priority: Major > > I tried to use new Java EE 8 Security API and noticed that javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated. But according to JavaDoc it should return false in this situation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4258) Intermittent failure in PropertiesAuthenticationDigestedTestCase.testBadUser

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4258?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4258: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Intermittent failure in PropertiesAuthenticationDigestedTestCase.testBadUser > ---------------------------------------------------------------------------- > > Key: WFCORE-4258 > URL: https://issues.jboss.org/browse/WFCORE-4258 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Brian Stansberry > Priority: Major > > https://ci.wildfly.org/viewLog.html?buildId=134022&buildTypeId=WildFlyCor... > {code} > java.lang.IllegalStateException: WFLYDM0043: No CallbackHandler available for mechanism DIGEST in realm TestRealm > at org.jboss.as.domain.management.security.SecurityRealmService.getCallbackHandlerService(SecurityRealmService.java:565) > at org.jboss.as.domain.management.security.SecurityRealmService.getAuthorizingCallbackHandler(SecurityRealmService.java:462) > at org.jboss.as.domain.management.security.realms.PropertiesAuthenticationDigestedTestCase.testBadUser(PropertiesAuthenticationDigestedTestCase.java:125) > {code} > TeamCity shows 3 failures in the past month. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4259) Upgrade WildFly Elytron to 1.9.x

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4259?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-4259: ------------------------------------- Summary: Upgrade WildFly Elytron to 1.9.x (was: Upgrade WildFly Elytron to 1.8.x) > Upgrade WildFly Elytron to 1.9.x > -------------------------------- > > Key: WFCORE-4259 > URL: https://issues.jboss.org/browse/WFCORE-4259 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4301) Upgrade remotingjmx to 3.1.0

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4301?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-4301. -------------------------------------- Resolution: Rejected Recent fixes have been included in 3.0.1.Final > Upgrade remotingjmx to 3.1.0 > ---------------------------- > > Key: WFCORE-4301 > URL: https://issues.jboss.org/browse/WFCORE-4301 > Project: WildFly Core > Issue Type: Bug > Reporter: Flavia Rainone > Assignee: Darran Lofthouse > Priority: Major > > Upgrade remoting jmx at wildfly core to next version -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-3313: -------------------------------------- Assignee: (was: Darran Lofthouse) > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow), Web Sockets > Affects Versions: 8.1.0.CR1, 10.0.0.Final, 15.0.0.Final > Reporter: Markus D > Priority: Major > Attachments: websocket-different-principals-ejb-vs-socket.png, websocket-endpoint-security.war > > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-9702: -------------------------------------- Assignee: (was: Darran Lofthouse) > SSO Integration for Programmatic Authentication > ----------------------------------------------- > > Key: WFLY-9702 > URL: https://issues.jboss.org/browse/WFLY-9702 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security, Web (Undertow) > Reporter: Darran Lofthouse > Priority: Critical > > At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication. > In this scenario we don't have either a wrapped mechanism or a CallbackHandler. > Couple of options: > * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on. > * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication? > * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

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 March 2019