July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-163) Monthly file rotation will continually overwrite the rotated log file

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-163?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-163: --------------------------------- Fix Version/s: 1.1.2.CR1 1.2.3.GA 1.3.3.Final 1.4.4.Final 1.5.8.Final 2.0.7.Final 2.1.0.Alpha2 > Monthly file rotation will continually overwrite the rotated log file > --------------------------------------------------------------------- > > Key: LOGMGR-163 > URL: https://issues.jboss.org/browse/LOGMGR-163 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 1.1.2.CR1, 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.8.Final, 2.0.7.Final, 2.1.0.Alpha2 > > > When the next rollover time is calculated a {{java.util.Calendar}} is used. When rotated monthly the day of the week is set to 0 and 1 month is added. This causes the calendar to be set to the last day of the current month. > On the last day of the month this also causes the file to continually rotate with each log message written, overwriting the previous log message. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-163) Monthly file rotation will continually overwrite the rotated log file

by James Perkins (JIRA)

James Perkins created LOGMGR-163: ------------------------------------ Summary: Monthly file rotation will continually overwrite the rotated log file Key: LOGMGR-163 URL: https://issues.jboss.org/browse/LOGMGR-163 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins Priority: Blocker When the next rollover time is calculated a {{java.util.Calendar}} is used. When rotated monthly the day of the week is set to 0 and 1 month is added. This causes the calendar to be set to the last day of the current month. On the last day of the month this also causes the file to continually rotate with each log message written, overwriting the previous log message. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1696) Remove deprecated and legacy security realm integration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1696?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1696: ------------------------------------- Fix Version/s: (was: 4.0.0.Beta1) > Remove deprecated and legacy security realm integration > ------------------------------------------------------- > > Key: WFCORE-1696 > URL: https://issues.jboss.org/browse/WFCORE-1696 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > > At some point the legacy security realms and all of the related backwards compatibility integration should be removed leaving us with a pure Elytron backed solution. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1696) Remove deprecated and legacy security realm integration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1696?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1696: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Remove deprecated and legacy security realm integration > ------------------------------------------------------- > > Key: WFCORE-1696 > URL: https://issues.jboss.org/browse/WFCORE-1696 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > > At some point the legacy security realms and all of the related backwards compatibility integration should be removed leaving us with a pure Elytron backed solution. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2016: ------------------------------------- Fix Version/s: (was: 3.0.0.Beta29) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone@localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone@localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1944: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2060) Support Elytron RoleMapper categories

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2060?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2060: ------------------------------------- Fix Version/s: (was: 4.0.0.Beta1) > Support Elytron RoleMapper categories > ------------------------------------- > > Key: WFCORE-2060 > URL: https://issues.jboss.org/browse/WFCORE-2060 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > > (Support for this could be added later, just scheduling in current releases for now if we have time) > The Elytron role mapping configuration can contain different mappers for different categories, this issue is to make use of categories for management role mapping. > We need to decide if we use hard coded names, some naming convention which is part hard coded, part based on deployment or a fully configurable category. > On the access=authorization resource this could simply be an optional String 'role-category' if we go for configured. Possibly a boolean to state if we fallback to the default RoleMapping on the domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2016) Change sasl-authentication-factor for management auth works after reload, but not after server restart

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2016?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-2016: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Change sasl-authentication-factor for management auth works after reload, but not after server restart > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2016 > URL: https://issues.jboss.org/browse/WFCORE-2016 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Zach Rhoads > > I can successfully configure a new sasl-authentication-factory and assign it to the management interface: > {code} > /subsystem=elytron/filesystem-realm=exampleFsRealm:add(path=fs-realm-users,relative-to=jboss.server.config.dir) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add() > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:set-password(clear={password="password123"}) > /subsystem=elytron/filesystem-realm=exampleFsRealm/identity=user1:add-attribute(name=Roles, value=["Admin","Guest"]) > /subsystem=elytron/simple-role-decoder=from-roles-attribute:add(attribute=Roles) > /subsystem=elytron/security-domain=exampleFsSD:add(realms=[{realm=exampleFsRealm,role-decoder=from-roles-attribute}],default-realm=exampleFsRealm,permission-mapper=login-permission-mapper) > /subsystem=elytron/sasl-authentication-factory=example-sasl-auth:add(sasl-server-factory=configured,security-domain=exampleFsSD,mechanism-configurations=[{mechanism-name=DIGEST-MD5,mechanism-realm-configurations=[{realm-name=exampleSaslRealm}]}]) > /core-service=management/management-interface=http-interface:write-attribute(name=http-upgrade.sasl-authentication-factory, value=example-sasl-auth) > reload > {code} > after reload, i am forced to re-authenticate and it succeeds: > {code} > [standalone@localhost:9990 /] reload > Authenticating against security realm: exampleSaslRealm > Username: user1 > Password: > [standalone@localhost:9990 /] > {code} > Once i restart the server though and try to connect, i get a timeout: > {code} > $ ./jboss-cli.sh -c > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code} > It also fails if i force no local auth: > {code} > $ ./jboss-cli.sh -c --no-local-auth > Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out: WFLYPRT0023: Could not connect to remote+http://localhost:9990. The connection timed out > {code}/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2060) Support Elytron RoleMapper categories

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2060?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-2060: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Support Elytron RoleMapper categories > ------------------------------------- > > Key: WFCORE-2060 > URL: https://issues.jboss.org/browse/WFCORE-2060 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > > (Support for this could be added later, just scheduling in current releases for now if we have time) > The Elytron role mapping configuration can contain different mappers for different categories, this issue is to make use of categories for management role mapping. > We need to decide if we use hard coded names, some naming convention which is part hard coded, part based on deployment or a fully configurable category. > On the access=authorization resource this could simply be an optional String 'role-category' if we go for configured. Possibly a boolean to state if we fallback to the default RoleMapping on the domain. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2146) Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2146?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-2146: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter. > ------------------------------------------------------------------------------------------- > > Key: WFCORE-2146 > URL: https://issues.jboss.org/browse/WFCORE-2146 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Environment: CentOS release 6.8 (Final) > JBoss Admin Command-line Interface > JBOSS_HOME: /opt/wildfly/10.1.0 > JBoss AS release: 2.2.0.Final "Kenny" > JBoss AS product: WildFly Full 10.1.0.Final > JAVA_HOME: null > java.version: 1.8.0_40 > java.vm.vendor: Oracle Corporation > java.vm.version: 25.40-b25 > os.name: Linux > os.version: 4.6.3-1.el6.elrepo.x86_64 > Reporter: Daniel Draper > > When hooking up our Wildfly Application to our SSO (CAS) for authentication and delegating Authorization to a Security Realm and then using LDAP we ran into the following problem: > *Use Case* > We want to use authorization inside a Security-Realm through LDAP. > In our LDAP setup we have a Group-To-Principal matching of the form "_member=uid=x" OR "submember=uid=x_" depending on if the user was added manually or through an autodomain. > Unfortunately as far as we could tell using two attributes in the Polish Notation (as is required by [LDAP|https://ldapwiki.com/wiki/LDAP%20filters%20Syntax%20and%20Choices]) seems to be impossible for the wildfly configuration. We tried the following in the standalone-accounting.xml (in different iterations and ways to place the parenthesis) which all lead to an 'unbalanced Parenthesis' or similar error when starting up wildfly. > {code:xml} > <management> > <security-realms> > <security-realm name="bla"> > <authorization> > <ldap connection="ldap"> > <username-to-dn> > <username-is-dn/> > </username-to-dn> > <group-search group-name="SIMPLE" iterative="false" group-dn-attribute="cn" group-name-attribute="cn"> > <group-to-principal search-by="SIMPLE" base-dn="ou=roles,***" recursive="false"> > <membership-filter principal-attribute="|(submember=uid={0})(member=uid={0})"/> > </group-to-principal> > </group-search> > </ldap> > </authorization> > </security-realm> > </security-realms> > </management> > {code} > We then found the filterString is parsed the following way: (See [LdapGroupSearcherFactory#L115|https://github.com/wildfly/wildfly-core/blo...]) > {code:java} > this.filterString = String.format("(%s={0})", principalAttribute); > {code} > which seems to make multiple attribute names as a filter impossible, which makes our use case as above impossible. > Asked in [Forums|https://developer.jboss.org/thread/273435], but since I didn't get any answers for 3 weeks opening here. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 July 2017