August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-854) Fallback to FORM authentication when an invalid kerberos token is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-854?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-854: -------------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1131225|https://bugzilla.redhat.com/show_bug.cgi?id=1131225] from POST to MODIFIED > Fallback to FORM authentication when an invalid kerberos token is used > ---------------------------------------------------------------------- > > Key: SECURITY-854 > URL: https://issues.jboss.org/browse/SECURITY-854 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_4_Final > > > Negotiation will not fallback to FORM authentication if the client has a kerberos token from a different KDC than what JBoss is configured to use. > This results in the user getting presented with a 401 error and no way to login. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3743) Upgrade to JBoss Negotiation 2.3.4.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3743?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3743: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1131227|https://bugzilla.redhat.com/show_bug.cgi?id=1131227] from POST to MODIFIED > Upgrade to JBoss Negotiation 2.3.4.Final > ---------------------------------------- > > Key: WFLY-3743 > URL: https://issues.jboss.org/browse/WFLY-3743 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ASSIGNED to MODIFIED > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ASSIGNED to MODIFIED > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3762) Automate MIT license grant with pull player

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-3762: --------------------------------- Summary: Automate MIT license grant with pull player Key: WFLY-3762 URL: https://issues.jboss.org/browse/WFLY-3762 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tomaz Cerar Assignee: Tomaz Cerar Jason Greene: btw i was thinking we should automate that MIT license grant with pull player Jason Greene: much like that white list thing i wrote Tomaz Cerar: white-list, admin-list, contributor-list with some more metadata in contributor list Tomaz Cerar: like date of MIT license grant and original PR where it was done Jason Greene: basically Jason Greene: "We require that all contributions be provided under the terms of the MIT open source license (link to license). Do you agree to provide this contribution and all future contributions under these terms?" -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3761) Security realms does not validate JAAS references to security domains

by Nicky Mølholm (JIRA)

[ https://issues.jboss.org/browse/WFLY-3761?page=com.atlassian.jira.plugin.... ] Nicky Mølholm edited comment on WFLY-3761 at 8/22/14 7:00 AM: -------------------------------------------------------------- That sounds super [~dlofthouse] ! It sounds good that you are taking stuff like this into consideration for future versions. To be honest me and my colleague also fought a host of "silent" behavior problems in addition to the above previously. And it was really difficult for us to understand, properly, what errors we introduced. The problems was not related to using the default other domain plus ApplicationRealm configuration elements - but rather appeared once we tried to hook up a custom login module and use that from remoting, ejb etc. And I get your message with respect to the links - won't happen again :). Thanks was (Author: nmoelholm): That sounds super [~dlofthouse] ! It sounds good that you are taking stuff like this into consideration for future versions. To be hones me and my colleague also fought a host of "silent" behavior problems in addition to the above previously. And it was really difficult for us to understand, properly, what errors we introduced. The problems was not related to using the default other domain plus ApplicationRealm configuration elements - but rather appeared once we tried to hook up a custom login module and use that from remoting, ejb etc. And I get your message with respect to the links - won't happen again :). Thanks > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFLY-3761 > URL: https://issues.jboss.org/browse/WFLY-3761 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.1.0.Final > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > Fix For: Awaiting Volunteers > > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3761) Security realms does not validate JAAS references to security domains

by Nicky Mølholm (JIRA)

[ https://issues.jboss.org/browse/WFLY-3761?page=com.atlassian.jira.plugin.... ] Nicky Mølholm commented on WFLY-3761: ------------------------------------- That sounds super [~dlofthouse] ! It sounds good that you are taking stuff like this into consideration for future versions. To be hones me and my colleague also fought a host of "silent" behavior problems in addition to the above previously. And it was really difficult for us to understand, properly, what errors we introduced. The problems was not related to using the default other domain plus ApplicationRealm configuration elements - but rather appeared once we tried to hook up a custom login module and use that from remoting, ejb etc. And I get your message with respect to the links - won't happen again :). Thanks > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFLY-3761 > URL: https://issues.jboss.org/browse/WFLY-3761 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.1.0.Final > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > Fix For: Awaiting Volunteers > > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1197) Prefill does not work for the last connection url when HA Datasource failover is enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1197?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1197: ------------------------------------------------ Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1132188|https://bugzilla.redhat.com/show_bug.cgi?id=1132188] from POST to MODIFIED > Prefill does not work for the last connection url when HA Datasource failover is enabled > ---------------------------------------------------------------------------------------- > > Key: JBJCA-1197 > URL: https://issues.jboss.org/browse/JBJCA-1197 > Project: IronJacamar > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JDBC > Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta3 > Reporter: Masafumi Miura > Assignee: Masafumi Miura > Fix For: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4 > > > See [https://bugzilla.redhat.com/show_bug.cgi?id=1120892] -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3761) Security realms does not validate JAAS references to security domains

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3761?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3761: ---------------------------------------- Just updating the properties of this issue to reflect the current situation, security integration is currently being reworked to eliminate a whole host of problems that this realm / domain pairing brings and that effort is already underway - at this point in time it is not in our interest to divert our efforts away from the new solution to change something we are planning to transition away from anyway. One additional point, please include relevant configuration and log messages in the Jira issue itself rather than links to external repositories, there is nothing worse than coming to a Jira issue and finding the links out of date, in addition to that when the issue is indexed by search engines the lack of content in the issue can mean similar problems are not discovered when appropriate search terms are used. > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFLY-3761 > URL: https://issues.jboss.org/browse/WFLY-3761 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.1.0.Final > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > Fix For: Awaiting Volunteers > > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3761) Security realms does not validate JAAS references to security domains

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3761?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-3761: ----------------------------------- Assignee: (was: Darran Lofthouse) > Security realms does not validate JAAS references to security domains > --------------------------------------------------------------------- > > Key: WFLY-3761 > URL: https://issues.jboss.org/browse/WFLY-3761 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, Security > Affects Versions: 8.1.0.Final > Environment: Development Mac > Test Linux (Debian) > Reporter: Nicky Mølholm > Labels: jaas, logging, security, trace > Fix For: Awaiting Volunteers > > > *Problem* > In the server configuration file (standalone.xml) it is possible to define a security realm that points to a security domain that does not exist - and there is no error reporting of this at all. There is no trace information of this at all, either. > *Example* > * Download a stock Wildfly 8.1.0.Final > * Replace standalone.xml with this gist: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my logoutput too. Find it here: https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw... > *What is wrong with this behavior?* > The bootstrapping process must validate that the configuration is valid indeed. It really doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for some weird reason, that silence is "security" - then at least let us know of the errors on loglevel = TRACE. > *Why is this issue created?* > The silent behavior makes security configuration in Wildfly an _extremely expensive operation_ in terms of time spent by the average Java EE developer / administrator. I have created this issue because I want wildfly to help developers/administrators become better at spotting our errors - because, in the end, that is a tangible productivity booster. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 8 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 August 2014