[Patch] Strip off realm from usernames when using Kerberos

[nutello@…]

When using Kerberos authentication, Trac will use USER@REALM as the username. For example, the default template will show at the top "logged as ME@…". It would be great to tell Trac about a default realm (in the example, REALM.EXAMPLE.COM) which, when present, would be stripped off.

The simplest way to do this would be to offer a new attribute, shortauthname, so that templates can be tweaked to use that rather than trac.authname. The next step would be to change the codebase and the templates to use the short name when applicable. I am not familiar with the Trac internals, so I have no idea how hard or invasive that would be.

[Ian Leader <__ian.leader__@…>]

There has been discussion of a similar problem at ​http://lists.edgewall.com/archive/trac/2005-May/003166.html.

Presumably you want to strip away the realm completely, therefore you could store it in the regular authname, so there wouldn't be a need for a shortauthname.

[nutello@…]

Should I work on a patch relative to 0.8.4 or SVN? Do I just add support for a new parameter called 'auth_name_strip_regex' in the same code paths as #1121, with yet another argument in the Authorizator constructor?

[Ian Leader <__ian.leader__@…>]

Adding this functionality would allow for a number of possible ways of munging the username, so I would suggest an approach whereby:

• one parameter defines the munging approach (regexp, convert to lower case, other common cases that one might want to pre-define)
• a second parameter defines the regexp to be used if one is required

e.g.

...
modify_authname_type = ignore_auth_case
...

OR

...
modify_authname_type = regexp_strip
modify_authname_parameter = <a list of regular expressions to be matched and removed from the authname>
...

the ignore_auth_case parameter would at this point be depricated (or because it's never been included in a release, removed?). This would prevent the Authenticator gaining a new construuctor for every possible munging.

It's *probably* not worth doing this for 0.8 - I would work with the trunk, and just hack your own version of 0.8x if you need it now.

[nutello@…]

Ian, that's one direction that I was thinking of, but I was wondering what one would do if they wanted to perform two munging operations. I can see that probably, in our case, we want to strip off the realm/domain, as well as ignore case.

This is the point where things start to get convoluted. One solution could be to have a munging list, composed of pairs, e.g. {{ignore_auth_case, true}, {regex_strip, "@REALM.EXAMPLE.COM$, @EXAMPLE.COM$"}}.

I am not sure how hard that would be to parse with the current design.

[Ian Leader <__ian.leader__@…>]

You're absolutely right - unless there's an easy way of doing sed pipelines in Python you're going to have problems if you want more than one transformation applied to your authname.

All the conversation I've seen on this topic has been about stripping off text matching a single regexp, or lowering the case. Therefore something like the following is probably adequate:

...
strip_authname = <regexp that matches the part you want stripped from the authname>
ignore_auth_case = true | false
...

an empty (whitespace only) or missing strip_authname would mean that you do not want to strip anything and would be the default. I would suggest that the strip be applied before the lowering of the case.

[harald.radi@…]

Is this ticket going to be addressed in 0.10? I encountered the same problem. Though I fixed it for me already it would be nice to have this resolved in trac itself by a more general approach.

[jsiirola@…]

Strip realms specified in [notification] ignore_domains from authname

[jsiirola@…]

I have a situation that necessitates stripping off the Kerberos realm from an authenticated user name. In an environment (that I have no control over), it is possible for users to authenticate against two different realms. All users exist in both realms, and the current realm that Trac eventually sees depends on the user's current operating system and browser. This causes problems (particularly for ticket management) because Trac maps these realms as distinct users.

I propose that Trac leverage the recently-added ignore_domain option (in [notification]) to provide the list of Kerberos realms to strip off. This makes some sense, as the documentation for that option specifically calls out stripping off Kerberos realms as the design motivation.

I just attached a patch​ for auth.py (against branches/0.11-stable) that implements this.

There is a negative to this solution: the central system authentication is now relying on an option in [notification], and not in [trac] where it probably belongs. This might mean that the ignore_domain option should be move into [trac] (and be renamed), or add new option.

[sahendrickson@…]

See also a new directive: ​KrbLocalUserMapping On. Though, I can't tell if it is/will be supported. FYI.

[anonymous]

strip-realm-0_12.diff

[tgs@…]

I just added the same patch, but against the 0.12-stable branch. The first patch worked fine once I upped patch's fuzz-factor to 3.

[Christian Boos]

Funny, I just went through #7203 some hours ago, and the two tickets seem to address the same issue. Now to the patches: attachment:strip-realm-0.12.diff.2​ and attachment:Trac-0.11b2-strip-domain.2.patch:ticket:7203​ are the same, and doesn't use [notification] ignore_domains as suggested in comment:8, but unconditionally strip the domain. Have you tried instead the attachment:strip-auth-realms.diff​? Doesn't that fix the issue as well? I think [notification] use_short_addr serves a different purpose, as explained in its TracIni#notification-section doc.

So I'd currently favor something like attachment:strip-auth-realms.diff​ for fixing this issue with Kerberos domains (clean-up of that patch welcomed).