January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-431) Revisit enforcement of required file system permissions.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-431?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated WFLY-431: ---------------------------------- Fix Version/s: (was: 11.0.0.Alpha1) > Revisit enforcement of required file system permissions. > -------------------------------------------------------- > > Key: WFLY-431 > URL: https://issues.jboss.org/browse/WFLY-431 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > > Now that AS8 has moved to Java 7 we can re-visit the level of control we have over file system permissions, this can be from taking more control of the local authentication mechanism to ensure incorrect permissions are not inherited to verifying sensitive configuration files are not world readable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-483) Allow more control over authentication for server to server communication through remote-outbound-connection

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-483?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved WFLY-483. ----------------------------------- Resolution: Out of Date Server to server authentication is being handled by the changes introduced for WildFly Elytron. > Allow more control over authentication for server to server communication through remote-outbound-connection > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-483 > URL: https://issues.jboss.org/browse/WFLY-483 > Project: WildFly > Issue Type: Sub-task > Components: Remoting, Security > Reporter: jaikiran pai > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Alpha1 > > > Right now for server to server communication via a remote-outbound-connection, we expect a static username to be specified (along with the security realm). User applications which use this remote-outbound-connection, for example an EJB application, do not have much control over the user/pass information, since the username is static. This further acts a drawback since the username that's used to connect to the remote server will be used as the (application) user who invoked the EJB. > It would be good to allow more control over the authentication for the remote-outbound-connection. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1159) Allow configure SSL connection in stanalone.xml for email servers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1159?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1159: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Allow configure SSL connection in stanalone.xml for email servers > ----------------------------------------------------------------- > > Key: WFLY-1159 > URL: https://issues.jboss.org/browse/WFLY-1159 > Project: WildFly > Issue Type: Sub-task > Components: Mail > Reporter: Alexey Volkov > Assignee: Peter Skopek > Fix For: 11.0.0.Alpha1 > > > Allow to configure SSL connection to email servers into stanalone.xml > Here is the discussion into community https://community.jboss.org/thread/205364 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1159) Allow configure SSL connection in stanalone.xml for email servers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1159?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-1159: -------------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > Allow configure SSL connection in stanalone.xml for email servers > ----------------------------------------------------------------- > > Key: WFLY-1159 > URL: https://issues.jboss.org/browse/WFLY-1159 > Project: WildFly > Issue Type: Sub-task > Components: Mail > Reporter: Alexey Volkov > Assignee: Peter Skopek > > Allow to configure SSL connection to email servers into stanalone.xml > Here is the discussion into community https://community.jboss.org/thread/205364 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2440) Thread pool AccessControlContext Propagation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2440?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2440: ----------------------------------- Fix Version/s: (was: 11.0.0.Alpha1) > Thread pool AccessControlContext Propagation > -------------------------------------------- > > Key: WFLY-2440 > URL: https://issues.jboss.org/browse/WFLY-2440 > Project: WildFly > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > > A decision was made within Java that newly created threads should inherit the access control context of their creator. > In general this was justified on the basis that if you are creating a thread you want it to inherit the permissions you already have. > Once we introduce thread pooling that logic no longer makes as much sense and there is not the same relationship between the thread that triggers it's creation and the long term life of that thread. > This may affect components outside of WildFly but I am raising it here as a top level task. > Should also note that JBoss Threads does already have some protection built in if a security manager is in use but there are times the AccessControlContext will be used without a security manager so more control is required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3342) undertow subsystem authentication configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3342?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-3342. ------------------------------------ Resolution: Out of Date > undertow subsystem authentication configuration > ----------------------------------------------- > > Key: WFLY-3342 > URL: https://issues.jboss.org/browse/WFLY-3342 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Reporter: Travis De Silva > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > I have a use case where I have static content that I want only authorised web users to be able to access. In the standalone.xml file, I added the following config. > <filter-ref name="my-auth"/> under <location> and > <basic-auth name="my-auth" security-domain="other"/> under <handlers> > But I am getting following error > Caused by: java.lang.RuntimeException: JBAS017346: Could not construct handler for class: class io.undertow.security.handlers.AuthenticationCallHandler. with parameters {"security-domain" => "other"} > [~ctomc] Mentioned in the forum post that how undertow does authentication has changed significantly and subsystem configuration did not catch up with it properly and request a jira ticket be opened. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3282) Remote EJB invocations needs corrected ports and protocol

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3282?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-3282. ------------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Remote EJB invocations needs corrected ports and protocol > --------------------------------------------------------- > > Key: WFLY-3282 > URL: https://issues.jboss.org/browse/WFLY-3282 > Project: WildFly > Issue Type: Bug > Components: Documentation > Affects Versions: 8.1.0.CR1 > Reporter: Paul Benedict > Assignee: Darran Lofthouse > Priority: Minor > Labels: jndi, remoting > Fix For: 11.0.0.Alpha1 > > > This page needs updating. > 1) It refers to old "remote" protocol but WildFly only supports "http-remoting" through HTTP Upgrade. > 2) All links to other pages point to AS71 not WFLY8. > https://docs.jboss.org/author/display/WFLY8/Remote+EJB+invocations+via+JN... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5431) Enable Elytron backed security for Undertow handled deployments.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5431?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5431. ------------------------------------ Resolution: Done > Enable Elytron backed security for Undertow handled deployments. > ---------------------------------------------------------------- > > Key: WFLY-5431 > URL: https://issues.jboss.org/browse/WFLY-5431 > Project: WildFly > Issue Type: Sub-task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5740) ContextPolicy checks purely based on names, ignores Principal types

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5740?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-5740: -------------------------------------- Assignee: Pedro Igor (was: Darran Lofthouse) > ContextPolicy checks purely based on names, ignores Principal types > ------------------------------------------------------------------- > > Key: WFLY-5740 > URL: https://issues.jboss.org/browse/WFLY-5740 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.CR4 > Reporter: Arjan t > Assignee: Pedro Igor > > In {{org.jboss.security.jacc.ContextPolicy}} the {{implies}} method only looks at the names of each {{Principal}} from the passed in {{ProtectionDomain}}, without checking if they're actually a role. > The collection of these names is then used to check against role based permissions. > If a user now has a name "expert" and there's also a role called "expert", access will be granted purely based on the user (caller) name. This is of course not correct. > See the following code: > {code:java} > // Check principal to role permissions > Principal[] principals = domain.getPrincipals(); > int length = principals != null ? principals.length : 0; > ArrayList<String> principalNames = new ArrayList<String>(); > for (int n = 0; n < length; n ++) { > Principal p = principals[n]; > if( p instanceof Group ) { > Group g = (Group) p; > Enumeration<? extends Principal> iter = g.members(); > while(iter.hasMoreElements()) { > p = iter.nextElement(); > // *** ONLY NAME IS USED. TYPE IS IGNORED > String name = p.getName(); > principalNames.add(name); > } > } > else { > String name = p.getName(); > // *** ONLY NAME IS USED. TYPE IS IGNORED > principalNames.add(name); > } > } > principalNames.add(ANY_AUTHENTICATED_USER_ROLE); > for (int n = 0; implied == false && n < principalNames.size(); n ++) { > String name = principalNames.get(n); > // *** "name", WHICH CAN BE ANYTHING, USED FOR ROLE NAME HERE > Permissions perms = rolePermissions.get(name); > if( perms == null ) > continue; > implied = perms.implies(permission); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5775) Use Elytron authentication mechanism where appropriate for deployments handled by Undertow.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5775?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5775. ------------------------------------ Resolution: Done > Use Elytron authentication mechanism where appropriate for deployments handled by Undertow. > ------------------------------------------------------------------------------------------- > > Key: WFLY-5775 > URL: https://issues.jboss.org/browse/WFLY-5775 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_eltron > Fix For: 11.0.0.Alpha1 > > > If we have a mapping from a security domain to an Elytron HTTP authentication definition we use that definition, otherwise fall back to existing behaviour as JAAS backed security domain and Undertow authentication mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 2017