We’re running Jira Data Center 8.20.10. We’ve had a a Seraph authentication plugin for a large number of years now, that has generally worked as we’d like it to. We disable the login gadget and alter the seraph config to provide a new login and login link URL (this points to a custom-login.jsp we put into the web folder), and we define the custom authenticator class.
This class replaces the getUser call with custom code that checks if the user is already signed in and returns it, checks if the user is allowed to perform basic auth (if that’s what they are doing), and if the user isn’t signed in, sets the os_destination property in the session, along with an SSO URL as well, and then lets the custom-login.jsp handle it (which it does by simply redirecting them off to some SAML signin). When the user returns to the same page, the authenticator is called to retrieve the user. The incoming SAMLResponse is read, decoded, and validated. If it’s all good, we log the user (or create them), and then return that user.
In this last step, since os_destination is set, the user is automatically redirected to their first destination. So, for clicking Jira links in e-mail or similar, this works a champ. And if you are simply clicking the login on the system dashboard, it works fine as well.
The whole process generally works through JSM as well. We want all users to have signed in with the company SSO. Which they go off and do. Here’s where things get a little odd though. If the user was trying to access say /jira/servicedesk/customer/portal/9, we store the full URL in the os_destination, and when the user returns, we’d want to restore that. However, if the user is a licensed user, the os_destination is followed and the user ends up on their queue. When the user has no license (IE: they are a ‘customer’), then they end up on /jira/service/customer/portals. This is generally ungood, as we want people who came from other apps to end up directly at the customer portal they wanted.
I’ve added a bunch of debugging statements, and it seems that os_destination is still set. I can see the incoming SAMLResponse, the decoding, and even a statement saying that we set the os_destination as before. However, the next requests after that are for the generic portals endpoint.
Is there a different redirect property, or some mangling of service desk URL’s I need to do to get the user signed into service desk first, so that the redirect will happen. I’ve banged my head on this one a while, but can’t come up with anything.
I tried forcing a redirect from the getUser call, but that won’t work as the response has already been committed, so a redirect won’t work. I even thought perhaps I could handle the os_destination in the custom-login.jsp we have (since it does take the SSO url from the authenticator and redirect the user to that URL – again, since we can’t redirect from the authenticator itself), but it seems that control doesn’t actually pass to that JSP again. It’s instead getting snapped up right after we return the user from getUser. I’ve tried also forcing a static full path (not an absolute URL like we have now), and that also didn’t work. I haven’t tried forcing a different os_destination entirely yet (say to google, or perhaps just the regular dashboard), because I believe the user will be redirected to the customer portals anyway.
Hence why I think there’s some other service desk property that needs setting that I’m not, that checks if a user is signed in before dropping them into the proper queue. Since they aren’t, it leaves them at the customer portals page, which does complete its flow and sign them in. But at that point, they’ve gone away from their context.
So, after running out of ideas, I’m here looking to see if the community has any suggestions on what to look at next. FWIW, I would use the new SSO for SAML/OAuth, however, I don’t want to manage groups through it, and unfortunately doing JIT use creation requires groups. Our company SSO is not in our control, so we can’t influence it in a meaningful way. And building our own just for this is a bit excessive. So, that’s not an option. I have considered trying to write our own SSO plugin (hopefully to add a new dropdown entry to the OIDC/SAML page), but can’t find any documentation on how that might work.
Thanks again for any help you guys can drum up!