Edgewall Software
Modify

Opened 14 years ago

Last modified 11 months ago

#1804 new defect

[Patch] Strip off realm from usernames when using Kerberos

Reported by: nutello@… Owned by:
Priority: normal Milestone: next-major-releases
Component: general Version: 0.8.4
Severity: normal Keywords: username authname patch
Cc: jsiirola@… Branch:
Release Notes:
API Changes:

Description

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.

Attachments (2)

strip-auth-realms.diff (1.8 KB ) - added by jsiirola@… 11 years ago.
Strip realms specified in [notification] ignore_domains from authname
strip-realm-0.12.diff.2 (2.0 KB ) - added by anonymous 9 years ago.
strip-realm-0_12.diff

Download all attachments as: .zip

Change History (15)

comment:1 by Ian Leader <__ian.leader__@…>, 14 years ago

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.

comment:2 by nutello@…, 14 years ago

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?

comment:3 by Ian Leader <__ian.leader__@…>, 14 years ago

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.

comment:4 by nutello@…, 14 years ago

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.

comment:5 by Ian Leader <__ian.leader__@…>, 14 years ago

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.

comment:6 by harald.radi@…, 14 years ago

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.

comment:7 by Christian Boos, 13 years ago

Keywords: username authname added
Milestone: 0.12

by jsiirola@…, 11 years ago

Attachment: strip-auth-realms.diff added

Strip realms specified in [notification] ignore_domains from authname

comment:8 by jsiirola@…, 11 years ago

Cc: jsiirola@… added
Keywords: patch added

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.

comment:9 by sahendrickson@…, 10 years ago

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

by anonymous, 9 years ago

Attachment: strip-realm-0.12.diff.2 added

strip-realm-0_12.diff

comment:10 by tgs@…, 9 years ago

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.

comment:11 by Christian Boos, 9 years ago

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).

comment:12 by Ryan J Ollos, 5 years ago

Owner: Jonas Borgström removed

comment:13 by figaro, 4 years ago

Summary: Strip off realm from usernames[Patch] Strip off realm from usernames when using Kerberos

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.