WebExternalAuth AND an RT::Authen::ExternalAuth LDAP ExternalInfo provider..?

I’m using (aspiring to use) apache’s mod_auth_cas to do external
authentication, plus RT::Authen::ExternalAuth as an info provider to
provide information about the apache-supplied username.

Is this actually possible? RT 3.8.4. Basically, the idea is to use our
common CAS SSO setup to provide usernames to RT, and then to rely on LDAP
if the user doesn’t already exist in order to create the new account.

Unfortunately, putting RT::Authen::ExternalAuth on the @Plugins appears to
disable WebExternalAuth.

Can this be made to work? And if so, how?

Cheers,
jan

jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 jan's very old home page
Just because I have nothing to hide doesn’t mean I have nothing to fear.

I’m using (aspiring to use) apache’s mod_auth_cas to do external
authentication, plus RT::Authen::ExternalAuth as an info provider to
provide information about the apache-supplied username.

Is this actually possible? RT 3.8.4. Basically, the idea is to use our
common CAS SSO setup to provide usernames to RT, and then to rely on LDAP
if the user doesn’t already exist in order to create the new account.

Unfortunately, putting RT::Authen::ExternalAuth on the @Plugins appears to
disable WebExternalAuth.

Can this be made to work? And if so, how?

Okay. With help from IRC this appears to be doable, but requires
additional code (rather than just configuration) to achieve what we’re
after (unless anyone knows better).

We use apache mod_auth_cas; turn on WebExternalAuth and so on:

Set($WebExternalAuth, 1);
Set($WebFallbackToInternalAuth , 1);
Set($WebExternalAuto, 1);
Set($AutoCreate, {Privileged => 1}); # or whatver you need here

I’ve then got

Set($ExternalAuthPriority, [ ]);
Set($ExternalInfoPriority, [ ‘My_LDAP’ ]);

to populate some fields (just following the example supplied in the
plugin).

What’s missing:

I’d at least like to be able to use LDAP group membership to supply the
initial group membership of newly-created users within RT. Without this
there’s little point actually using the LDAP module since I’m going to
have to prepopulate RT with my users anyway :frowning:

Having looked a bit further at this, it also seems like the “rt”
command-line tool hasn’t really moved on from 3.6; I hacked some code to
support a few more operations against types that weren’t “ticket” back
then.

  • are there hooks for user creation that I can write minimally-invasive
    code for in order to grab what I need out of LDAP?

  • Are there plans to complete support for non-ticket types with the rt
    command-line tool?

  • if not, what’s the recommended route for scripted creation of queues,
    groups, users, etc?

  • what FM should I be Ring for this? :slight_smile:

What’d be lovely:

It’d be really, really nice if RT had a completely pluggable system for
supplying group membership information on the fly. I realise that there
are some issues with this and the cached group membership that RT does
under the hood, and in particular the generation of ACL queries would need
a rethink; but as far as I can see at the moment any hope of doing some
live integration with an external group manager is going to be a bit of a
bodge, to say the least. Maybe in RT 4?

jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/
Tel +44 (0)117 3317661 jan's very old home page
Ceci n’est pas une pipe |