Simon Hausmann
My feedback
1 result found
-
241 votes
Work has begun to support OpenID Connect, which enables one to use any OAuth 2.0 identity solution. It is planned for Mattermost Cloud and Mattermost Self-Managed E20.
An error occurred while saving the comment An error occurred while saving the comment Simon Hausmann
commented
Could you elaborate how (1) and (2) stand in the light of gitlab support? If you intend to support gitlab SSO in the apps, then you'll end up with pretty generic code in the ios/android apps anyway, won't you?
As far as I can see gitlab acts as oauth provider. As the pull request demonstrates, it's fairly easy to generalize the back-end code in mattermost to be provider agnostic. There is work to be done to simplify this on the front-end while maintaining the sso service branding, but that doesn't seem to be an insurmountable task :)
Just to clarify: I'm willing to put in time to work on this and contribute it. We just need to agree on the direction :). I see an opportunity to clean up code in MM most and I'm happy to contribute golang tests for the code.
Simon Hausmann
supported this idea
·
Thanks for your response - I think I understand your concerns a little better now. I also agree that the user experience with oauth based SSO is tricky to get right so that it feels natural and easy. This also includes the administrative side of the user interface.
That said, I think it's possible to improve the automated test coverage of the SSO code paths - potentially to an extend that you can reduce the manual work quite a bit. Once/If I get the CLA signed from my employer then I'll see if I can contribute changes that demonstrate what I have in mind. But that doesn't help much with this particular item and our use-case:
I consider proposing the use of mattermost to a wider audience of contributors in the Qt project (qt-project.org). There are a couple of things on the way, but from a technical perspective the biggest hurdle right now is that we'd use OAuth based SSO. Every contributor in the Qt project has a so-called Qt Account and we have an oauth provider set up for that.
From an administrative side this is a matter of setting up mattermost and adding the oauth urls for the qt account into the system console settings (that the aforementioned github pull-request adds). After that it works and we're evaluating it at the moment.
In the long run I think that the ability to use external identity and authentication providers is crucial for large scale deployments of web applications. With projects like rocket chat this is already possible, hence my interested in seeing this generalization also in mattermost.
I really think that back-end wise this is a pretty straight-forward piece of work. From the perspective of the end-users the work flow is always the same, as mandated by oauth itself. What remains is the aspect of testing, how the administrator conveniently and forgivingly configures the SSO (I do like your design principles :) and lastly a step of verification against the external service ("does the userinfo api return all the correct values needed").