We would like to set up our self hosted Octopus instance to allow SSO via our ADFS system. We would like to configure it so that users browsing to the Octopus GUI are automatically redirected to our ADFS login page without any other interaction (ie any login dialogues, buttons, etc), are authenticated, then returned to the Octopus GUI having been logged in.
I have managed to get this working on a test instance of Octopus by using the built in Okta extension, and instead of configuring it to use Okta, pointing it at our ADFS OIDC configuration instead. This works well, and does exactly what we want.
However our problem is that on our live Octopus instance, we have the Active Directory extension enabled so that we can set permissions on AD groups. Currently users log in using the AD extension, but we would want to remove this ability in favour of SSO via ADFS instead. When this extension is enabled on the test instance, the SSO login flow changes to include an Octopus GUI page asking users to either ‘Sign in with a domain account’ or ‘Sign in with Okta’.
We’d really like to avoid this, as it’s confusing for our users. I assume this is happening because of the behaviour described here under Auto Login (‘this functionality is only active when there is a single, non forms-based authentication provider enabled’). However I also notice that under the settings for the Active Directory extension, there is an option where I can disable Forms Authentication for Domain Users. I might have thought that disabling this would return the behaviour to as we need it, but it doesn’t.
Is there any way to make this work? Or do we have to choose between using SSO, and being able to assign permissions via AD group in order to get a seamless login experience?
Alternately, is there any way to customise the login dialogue page which appears when both AD and Okta authentication is enabled?
Hi Simon,
Thanks for reaching out. I’m sorry to hear that you’re running into our lack of support for ADFS and for the delay in getting back to you.
Unfortunately, I do not have a great answer for you here. I’m unaware of a graceful way to make this work and fairly certain there’s no easy way of customizing the login page. I am reaching out to our Engineers to see if I’m overlooking an approach that may provide the result you’re looking for here.
I should have an update for you shortly. Thanks again for getting in touch.
Hi Simon,
I’m very sorry for the delay in getting back to you. Our engineers have been tossing around ideas but haven’t landed on any great solution.
One idea that was discussed but has not been verified in any way, and would likely be a heavy lift, is to split your AD provider into two providers. In this scenario the first provided would allow AD to sign in, the second would allow users to connect to AD groups to teams and AD identities to users and would handle the hourly sync. The second provider would need to be enabled for the first to work, but the second could be enabled in conjunction with an OIDC provider.
Again, this is just an idea that was discussed theoretically, but not tested. Would love to hear your thoughts on this.
Kind Regards,
Hello, thanks for the reply. That would probably work, as we just need some way of being able to use AD groups for permissions without enabling AD for logins.
I’m assuming anything like that would be some time away though?
Hi Simon,
Thank you for the feedback! I’ll pass that along to our Engineering team. Unfortunately, you are correct. If this is taken on, it would not be on the roadmap for this next year.
An alternative option that might work with the current implementation is to disable the AD provider and configure groups to come through the claims in ADFS. Would that be a possibility for you?