cachet
cachet copied to clipboard
cachethq
Implementing SSO with SAML
Hi, More and more companies are using Cachet as their status page. Many companies have an SSO Identity Provider (IdP) to manage their employees and it may be tedious for them to create an account manually (or using API) into the Cachet database. Implementing SSO as a Service Provider (SP) using SAML in Cachet would be a great help for them and would also help companies to adopt Cachet.
I am interested by implementing SSO in Cachet so I open this issue as an open discussion for guidelines, advices or anything. A PHP library manages the SAML part. I imagine that a company could configure some IdP in their Cachet instance and so on the login page we'd list all the configured IdP.
I'm open to all remark.
I'd be happy to support SSO, but I've no means of testing this. If someone wants to pick that up, that'd be great!
The users may be stored in an Identity Provider (IdP) or in the Cachet's database. On the login page we can choose either to login using the form or one of the configured IdP. On its first login using an IdP, the user is created into the database but this process is hidden (no email sent). This account is only used to create components, incidents, and so on. The user will not know the account is effectively created into Cachet.
The SSO would be SP initiated.
A second step would be to support SLO (Single Log Out) in order to log out the user if he is logged out from its IdP.
During development:
- Saml-ipd is a good IdP for development only
- Shibboleth is a great IdP
- SimpleSamlPhp seems to be good too
I suggest to install locally one IdP (saml-idp is really easy to use), use the one login's or simplesamlphp's library to handle SAML, and begin the configuration of the IdP listed on the login page before handling SAML.
If you're ok with that I'd begin with that.
Hi, php-saml maintainer here. Let me know if you have any doubt with the SAML toolkit or how to do the integration.
Best regards.
@pitbulk It seems the php-saml library requires the mcrypt extension, but this extension is removed in PHP 7.2. Is there any plan to change that? I really like this library because if its ease to use, but this point blocks me.
Great! Thanks for this information @pitbulk . Is this branch stable enough to be used in production?
I've installed an Identity Provider (SimpleSamlPhp) on my local machine, but I wait for the roadmap (#2943) to know if it's a priority or not.
@anthonybocci we should definitely make SSO part of the 3.0 release. If we're smart, we could allow GitHub, Twitter, Facebook login etc.
SSO for GitHub, Twitter, etc is based on OAuth2 (OpenID Connect in particular), so it's using different mechanism than SAML. Anyways OIDC support would be great too.
Per #2108 maybe we should open a single issue for improved authentication mechanisms?
@jbrooksuk I think the common issue you are speaking about could be about a user/login modification in order to be as flexible as possible. But as what I read in #2108, the authentication logics are really different so it would be hard to manage all in one issue. We could imagine first a kind of "login plugin" logic, and we implement this logic for every "plugin" or class. Cachet's controller would call the "login plugin" that was selected, and has no real idea about if it's a database, SAML, OIDC or LDAP. Once this logic is ready, done, tested, future-proof and implemented for the database, we could implement as many SSO as we want.
Hi, I would like to know if this is a work in progress or it is stacked somehow.
Hi @titansmc, I'm still there and still available to implement SSO/SAMLV2, but the work hasn't begin on this point yet.
We are doing some stuffs on Cachet before, like working on documentation, making it more robust and so on. When we'll be ready, I'll begin the work on SSO.
@jbrooksuk @anthonybocci Will Laravel's Sociallite not be a better solution? Then you have the most SSO providers at once.
https://laravel.com/docs/5.4/socialite https://socialiteproviders.github.io/ https://github.com/SocialiteProviders/Providers/tree/master/src
@steffjenl Thank you for your contribution, it's an interesting idea!
I had in idea that companies will use an internal Identity Provider to manage their users. Why a company would allow anybody on Twitter or other to create an account on their status page?
May we use Sociallite and add a custom manager in order to manage their internal Identity Provider?
@anthonybocci sorry for my late answer. It is not only Twitter or other socialnetworks.
- Microsoft Azure (Office 365)
- GitHub
- GitLab (https://github.com/SocialiteProviders/Providers/tree/master/src/GitLab)
- Zenddesk
- Jira (https://github.com/SocialiteProviders/Providers/tree/master/src/Jira)
- Bitbucket
Most company's use Microsoft Office 365 or Google products for e-mail and Jira orZendesk for ticket system (dev/support) or GitLab, GitHub or Bitbucket for version control.
And if that is not enough, you can always make your own socialite provider for your own internal Identity Provider.
Sorry my mistake, Socialite is only with OAuth. The problem is still there if you only use an internal Identity Provider. But if you use a local Active Directory you could install ADFS 3.0.
https://github.com/SocialiteProviders/Manager https://blog.scottlogic.com/2015/03/09/OAUTH2-Authentication-with-ADFS-3.0.html
Socialite would be a good solution. I've used it at work with Azure previously. It doesn't solve the SAML issue though...
@jbrooksuk According to you, what software do companies use SAML as an Identity Provider? Microsoft Active Directory using ADFS for SAML and OAuth.
Is it a good idea if I create a test environment with ADFS with OAuth and a creating an Socialite provider?
@steffjenl I'm unsure to be honest, but @anthonybocci opened an issue regarding it, so people must use it?
I think we need to be careful that we don't support too many providers and make it confusing.
@steffjenl I like the idea, using this package to manage many providers is really interesting. That was not how I imagined the issue so I'll try to explain a bit more and tell me what you think.
People may be using things like Microsoft Azure, Saleforce of what ever they want. I didn't think about supporting one or an other Identity Provider. I did think about being a generic Service Provider.
So according to me it's easier to support SAMLV2, have a configuration about signature/encryption etc, and allow our users to configure any Identity Provider. It's only about SAMLV2 so it may be Microsoft of other, it's the same.
This way, we can avoid to claim the support of many providers. We would be only a Service Provider that they can configure.
That’s be decent, but it would mean that people need to install other socialite providers if they need them. Is that ideal? They do require code changes.
Hi @preetpal13, There is no ETA now because it remains lot to do. In an other project I'm implementing SAMLV2 in Symfony 4.1 so I'm still excited by this subject. But before working on SSO in Cachet there are some things to do, like make it more stable, work on security, GPRD and so on. The roadmap already says that I think, so we follow it :)
+1 for SAML. We want to roll this out internally with Okta as our IdP. I'm happy to help with any testing you need once it gets to that point.
@spencerryan thank you for your help. Before building, using or testing anything we need to choose really with @jbrooksuk the way we create this feature.
This issues was created long time ago, I think we have to choose. Once done, we'll begin it as soon as problems with higher priority are solved.
I think someone mentioned that SAML is possible with the REMOTE_USER stuff.