<div dir="ltr">Hi Community,<div><br></div><div>Over the past few months, I've been contemplating what we need from an Identity replacement to meet the needs of our web services both now and into the future - especially given the current condition of Identity.</div><div><br></div><div>This also involves evaluating whether this is something that truly needs to be completely custom - or whether it can be something off the shelf.<div><br>As it is modern security best practice to not get people comfortable with logging in using their credentials on any site, the new service must be able to support this practice - with OAuth2 being the best placed in a modern context to do so.<br><br>The list of requirements that results from this is:<br>- User profiles that contain a name and email address(es)<br>- Groups that users belong to, with the possibility of delegating management to non-Sysadmins<br>- Support for strong 2FA methods (TOTP at a minimum, with U2F/FIDO2 being preferred)<br>- Support for 'application passwords' to allow us to support systems that cannot handle OAuth2 based authentication (such as SMTP)<br><br>On investigation most systems that are dedicated "identity providers" are both very heavy, complex and don't meet our needs very well (usually lacking self-service registration and password reset systems, as they're designed for corporate use).</div><div>While they do tend to support other protocols for Identity Federation as well (like SAML) those aren't necessary for our purposes and simply create additional security risk.</div><div><br>We are already running a very capable and well supported bit of software that can act as an OAuth2 provider (and ticks all the other above boxes) and has pre-existing support available for most of the web software we run though - Gitlab.</div><div><br>Given that reinventing the wheel is both expensive and risky (requiring volunteer time to maintain, requiring us to keep on top of any security issues in the underlying stack ourselves, etc) i'm very much in favour of using something 'off the shelf'.</div><div>Additionally some of the software we may want to use in the future is very likely to want to talk to Gitlab (to interact with issues, commit to repositories on behalf of users, etc) which requires that application to interface with Gitlab directly anyway.<br><br>I'd therefore like to move away from both Identity and MyKDE to Gitlab.<br><br>Because we are already populating most group information, as well as names and email addresses in Gitlab the 'migration' of data part of the equation is mostly completed already. When we finally 'cut the cord' and shutdown Identity people would need to perform a password reset to regain access but that would be the only point of pain. Those people who haven't logged into Gitlab by the point we 'cut the cord' would have their information deleted (unless they hold a Developer account or are an e.V. member in which case we would provision an account for them with their data) as the information would be considered to be information that is no longer required.</div><div><br>The only risk I can see is that we would be putting quite a few eggs in one basket, however given the success of Gitlab I think that risk at this stage should be fairly minimal (and is no higher than if we went with something else off the shelf).<br><br>Comments?<br><br>Thanks,<br>Ben<br></div></div></div>