WebRemoteUserAuth with CLI and/or REST

1

I’m attempting to use RT CLI and REST for the first time. We have WebRemoteUserAuth enabled and use cosign for SSO.

In order to authenticate against the REST path we have disabled cosign for that specific path only. We are hopeful that enabling WebFallbackToRTLogin we allow us to successfully authenticate a local RT user account then use curl to create tickets via REST. If anyone has suggestions for other methods for doing this I’d love to hear them.

I am also trying to use the CLI. Since we cannot disable SSO for the entire domain it seems maybe not possible to use the CLI when RT is configured to use webauth. Is there another way?

Thanks!

1 Like
2

In case someone finds this thread and wishes it had an answer:

  1. Modify your web config to disable your SSO for the REST path: yourwebroot/REST/1.0/.
  2. Add Set( $WebFallbackToRTLogin, 1); to your RT_SiteConfig.pm
  3. Create a user account in the RT GUI. Enable “Let this user access RT” and “Let this user be granted rights”. You may need to adjust permissions so that the user can do whatever it is you want it to do. We’re only creating tickets and have RT configured to allow anyone to create tickets so we did not modify the permissions of this user.
  4. Set a password for that user. There may be other ways to do this but we just modified the database directly: perl -I/opt/rt4/local/lib -I/opt/rt4/lib \ > -MRT -MRT::User \ > -e'RT::LoadConfig(); RT::Init(); my $u = RT::User→new($RT::SystemUser); $u→Load(“THE-USER-ACCOUNT-YOU-CREATED”); $u→SetPassword(“THE-PASSWORD-YOU-WANT”)'

You now have a user account that can be used with the REST API, even though you’re using SSO.

3

Helpful to hear your workaround.

Wanted to add for reference that, while the documentation for RT::Authen::Token would seem to suggest “Once you have an authentication token, you may use it in place of a password”, tokens will not be accepted by the CLI in place of a password. I did basically the same thing you did, setting a password for the user account, to enable the CLI to authenticate.

I wonder if this will change in the future, or perhaps the CLI will be rearchitected around the REST2 API.