September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1881) Security Realm Trust - Users requesting to run as a different user e.g. $local to real user.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1881?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-1881. ------------------------------------ Resolution: Out of Date This whole area is being re-visited with Elytron. > Security Realm Trust - Users requesting to run as a different user e.g. $local to real user. > -------------------------------------------------------------------------------------------- > > Key: WFLY-1881 > URL: https://issues.jboss.org/browse/WFLY-1881 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2079) Update security realm <authorization /> to support multiple definitions.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2079?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-2079. ------------------------------------ Resolution: Out of Date This whole area is being re-visited with Elytron. > Update security realm <authorization /> to support multiple definitions. > ------------------------------------------------------------------------ > > Key: WFLY-2079 > URL: https://issues.jboss.org/browse/WFLY-2079 > Project: WildFly > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > > Complex configuration could result in different methods being used for authentication, as a result we may also need to support multiple sources for loading group membership information. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2127) Resurrect regular expression based group name identification for LDAP

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2127?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-2127. ------------------------------------ Fix Version/s: 9.0.0.Beta1 Resolution: Out of Date This whole area is being re-visited with Elytron. > Resurrect regular expression based group name identification for LDAP > --------------------------------------------------------------------- > > Key: WFLY-2127 > URL: https://issues.jboss.org/browse/WFLY-2127 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > Fix For: 9.0.0.Beta1 > > > The changes contributed under WFLY-455 contained a feature to extract the group name from the distinguished name based on a regular expression search - this should be resurrected as a third mode for group name identification. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1433) Enhance add-user utility to allow user to select from known groups when assigning groups to a user

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1433?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1433: ----------------------------------- Assignee: (was: Darran Lofthouse) > Enhance add-user utility to allow user to select from known groups when assigning groups to a user > -------------------------------------------------------------------------------------------------- > > Key: WFLY-1433 > URL: https://issues.jboss.org/browse/WFLY-1433 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Fix For: Awaiting Volunteers > > > Also ensure add-user utility is talking about groups and not roles. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2256) Add a TRACE level category for the operations used to start a server.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2256?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2256: ----------------------------------- Fix Version/s: Awaiting Volunteers (was: 9.0.0.Beta1) > Add a TRACE level category for the operations used to start a server. > --------------------------------------------------------------------- > > Key: WFLY-2256 > URL: https://issues.jboss.org/browse/WFLY-2256 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management, Logging > Reporter: Darran Lofthouse > Fix For: Awaiting Volunteers > > > Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server. > From a development perspective this is useful for double checking the operations are as we expect. > From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3314) LoginContext does not propagate Login

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3314?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-3314. ------------------------------------ Fix Version/s: 9.0.0.Beta1 Resolution: Rejected This is an issue that needs discussing in the forums. > LoginContext does not propagate Login > ------------------------------------- > > Key: WFLY-3314 > URL: https://issues.jboss.org/browse/WFLY-3314 > Project: WildFly > Issue Type: Bug > Reporter: Markus D > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > I am trying to do a manual login in an EJB like the Servlet Request offers. > So far so good. I implemented the CallbackHandler: > public class PasswordCallbackHandler implements CallbackHandler { > private String username; > private char[] password; > public PasswordCallbackHandler(String username, char[] password) { > super(); > this.username = username; > this.password = password; > } > public void handle(Callback[] callbacks) throws IOException, > UnsupportedCallbackException { > if(callbacks == null) { > return; > } > for (int i = 0; i < callbacks.length; i++) { > if (callbacks[i] instanceof NameCallback) { > NameCallback nc = (NameCallback) callbacks[i]; > nc.setName(username); > } else if (callbacks[i] instanceof PasswordCallback) { > PasswordCallback pc = (PasswordCallback) callbacks[i]; > pc.setPassword(password); > } else { > throw new UnsupportedCallbackException(callbacks[i], > "Unrecognized Callback"); > } > } > } > } > My Code: > PasswordCallbackHandler handler = new PasswordCallbackHandler("user", "password".toCharArray()); > LoginContext context = new LoginContext("realm", handler); > context.login(); > The subject shows: > Subject: > Principal: user > Principal: Roles(members:ADMIN,USER) > Principal: CallerPrincipal(members:user) > So the login itself worked. My Question now is what am I doing with it? When I fetch the current principal from the container I still receive anonymous. Tested on JBoss 7.1 and Wildfly. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > if(callerPrincipal == null) { > return null; > } > String name = callerPrincipal.getName(); // Also after login() it returns anonymous. > So did I misunderstood this functionality or should the container set the principal to the user I logged in? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2256) Add a TRACE level category for the operations used to start a server.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2256?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2256: ----------------------------------- Assignee: (was: Darran Lofthouse) > Add a TRACE level category for the operations used to start a server. > --------------------------------------------------------------------- > > Key: WFLY-2256 > URL: https://issues.jboss.org/browse/WFLY-2256 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management, Logging > Reporter: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > Sometimes after being able to start a server from the XML configuration it is useful to be able to identify the actual operations that are executed to start the server. > From a development perspective this is useful for double checking the operations are as we expect. > From an end user perspective this can be useful to identify the set of equivalent operations needed if the same was to be achieved in a CLI script. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3179) Dynamic Deployment of Security Domain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3179?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3179: ---------------------------------------- I have set to awaiting volunteers but in reality we are working on a replacement security implementation not dependent on JAAS domains. > Dynamic Deployment of Security Domain > ------------------------------------- > > Key: WFLY-3179 > URL: https://issues.jboss.org/browse/WFLY-3179 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Labels: security-domain > Fix For: Awaiting Volunteers > > > In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3179) Dynamic Deployment of Security Domain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3179?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3179: ----------------------------------- Assignee: (was: Darran Lofthouse) > Dynamic Deployment of Security Domain > ------------------------------------- > > Key: WFLY-3179 > URL: https://issues.jboss.org/browse/WFLY-3179 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Labels: security-domain > Fix For: Awaiting Volunteers > > > In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3179) Dynamic Deployment of Security Domain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3179?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3179: ----------------------------------- Fix Version/s: Awaiting Volunteers > Dynamic Deployment of Security Domain > ------------------------------------- > > Key: WFLY-3179 > URL: https://issues.jboss.org/browse/WFLY-3179 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: Darran Lofthouse > Labels: security-domain > Fix For: Awaiting Volunteers > > > In JBoss 6, security domains can be dynamically deployed using jboss-beans.xml, which is not working in WildFly 8. It would be quite useful to bring back this feature, so that no manual operations or extra scripts are needed to create security domains during application deployment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014