Minor Description
3:39 PM
We think we've found something of a bug with 2.5.60 after an upgrade yesterday. When an API user authenticates using HTTP basic, and they have a colon in their password, grouper seems to be parsing the authentication information incorrectly.
For example, if I'm authenticating using the (base64 encoding of) tfinney:What:ever123, it thinks that the password is What, instead of What:ever123.
Do you know offhand if this is a known issue and, if not, what's the optimal way to report it?
Chris Hyzer 5:33 PM
does this help?
https://todos.internet2.edu/browse/GRP-3163
5:38 PM
probably, thanks.
11:57 AM
Or not.
We tried the
grouper.authentication.splitBasicAuthOnFirstColon = false
As far as we can tell, this only does anything if you're using Grouper's internal authentication database. We're using LDAP for that.
edu.internet2.middleware.grouper.ws.security.WsGrouperLdapAuthntication calls
String user = GrouperUtil.prefixOrSuffix(unencodedString, ":", true);
String pass = GrouperUtil.prefixOrSuffix(unencodedString, ":", false);
to break username:password up. GrouperUtil,prefixOrSuffix does:
public static String prefixOrSuffix(String startString, String separator, boolean isPrefix) {
String prefixOrSuffix = null;
if (startString == null)
return startString;
int separatorIndex = isPrefix ? startString.indexOf(separator) : startString.lastIndexOf(separator);
if (separatorIndex == -1)
return startString;
int separatorLength = separator.length();
if (isPrefix)
else
{ prefixOrSuffix = startString.substring(separatorIndex + separatorLength, startString .length()); }
return prefixOrSuffix;
which takes everything up to the first : for the username and everything after the last colon the password.
so user:secretpass:word
would get turned into user and word, not user and secretpass:word
Chris Hyzer 1:23 PM
can you try escaping the colon as it says in the jira?
1:23
or setting a pass that doesnt have colon? that protocol sucks that uses colon without escaping
1:25 PM
We're actually right in the middle of a conversation about this, but I think "no one can use colons in passwords" is a suboptimal solution.
1:25
Does the escaping bit work when authenticating against ldap?
1:41 PM
So, we're looking at this, and RFC7617 says that usernames can never contain colons, so that string should always be splitting on the leftmost colon.
https://datatracker.ietf.org/doc/html/rfc7617
datatracker.ietf.orgdatatracker.ietf.org
RFC 7617 - The 'Basic' HTTP Authentication Scheme
The 'Basic' HTTP Authentication Scheme (RFC 7617)
1:51 PM
The change in 3163 does not apply when you're doing authentication via ldap. It only affects authentication via Grouper's internal system.
2:32 PM
We do not believe, based on looking at the source, that the colon escaping code will come into play for ldap authentication.
2:33
So, no, we can't escape the colon.
The solution for this today seems to be changing the password to remove the colon, but we strongly believe that this is a bug.
2:44 PM
Yes, true is actually what we tried, because per RFC7617, is should always split on the first colon, because colons are not permitted in usernames.
And, again, as I said, that change does not do anything at all when it comes to ldap authentication. It's never called. It's only used when you're using Grouper's internal authentication.