[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-815:
--------------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from MODIFIED to ON_QA
> NegotiationAuthenticator loses post data
> ----------------------------------------
>
> Key: SECURITY-815
> URL: https://issues.jboss.org/browse/SECURITY-815
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_5
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_3_0_CR2
>
>
> The NegotiationAuthenticator loses post data.
> A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
> If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
> If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-640:
--------------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1085497|https://bugzilla.redhat.com/show_bug.cgi?id=1085497] from MODIFIED to ON_QA
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from MODIFIED to ON_QA
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (SECURITY-819) LdapExt login module fetches to many attributes in RoleSearch
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-819?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-819:
---------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1086787, https://bugzilla.redhat.com/show_bug.cgi?id=1086795, https://bugzilla.redhat.com/show_bug.cgi?id=1089068 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1086787, https://bugzilla.redhat.com/show_bug.cgi?id=1086795)
> LdapExt login module fetches to many attributes in RoleSearch
> -------------------------------------------------------------
>
> Key: SECURITY-819
> URL: https://issues.jboss.org/browse/SECURITY-819
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_21.Beta3
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
>
> An LDAP server with (lets say) 1000 users in a group.
> When authentication, a query is done to retrieve the groups for the user.
> Most LDAP servers will limit the attributes send back based on authorization of the user, but can be configured to return *all* information.
> The cause is:
> / Query for roles matching the role filter
> SearchControls constraints = new SearchControls();
> constraints.setSearchScope(searchScope);
> constraints.setTimeLimit(searchTimeLimit);
> rolesSearch(ctx, constraints, username, userDN, recursion, 0);
> this used to also have:
> constraints.setReturningAttributes(new String[0]);
> at some time this was taken out.
> It needs to go back in
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3226) Add test cases to verify LDAP caching on security realms.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3226?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-3226:
------------------------------------
Hi, I would like to try resolve this issue. How can I become assignee?
(Restricted to jira-users group)
> Add test cases to verify LDAP caching on security realms.
> ---------------------------------------------------------
>
> Key: WFLY-3226
> URL: https://issues.jboss.org/browse/WFLY-3226
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Test Suite
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> The existing test cases are based on a statically defined set of LDIFs, testing of caching could consider a couple of options: -
> 1 - Interceptors within ApacheDS to verify if calls hit the directory.
> 2 - Updates to the directory that would affect the outcome of tests if there is a cache hit, tests can then be repeated with and without clearing the cache.
> Note: It would be beneficial for this to use different users and groups and maybe even different partitions so that test ordering does not affect the outcome if changes are made to the directory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months