Sorry, right now this is limited to Hosted-Setup only, as the source code still lurks around the private repo. ;(
Got the mapping issue figured out, it does map just fine if the correct SAML attribute is sent: email and the email attribute sent matches the “email” field in the Zammad local user. I was having trouble with the existing users that i tried initially without the proper mapping configured, new users are mapping great.
The only problem now is how do i remove the “bad” users that have the number appended to the login? setting them to inactive doesn’t work, and i can’t delete via the database on the hosted instance. So the users i attempted to login with initially are forever unmappable to their corresponding local Zammad account it seems.
Great news though, the saml implementation if configured correctly from the get go, is working perfectly.
On Hosted Setups, as long as you’re not able to do so via UI, we do that for customers. (I mean beside API option, but that only works if you never logged in).
Just drop a mail to support [at] zammad [dot] com and tell us which users (best is to provide the mail addresses or loginnames)
Hey @carl2187 - Thanks again for your great support on testing this. I have a really good feeling now to make this public and add it to the upcoming 3.2 release. Before that I can see 2 tasks:
- Add a comprehensive SAML documentation to the other third party auth providers of our admin documentation.
- Have a public beta test for our on-premise user base.
I don’t want to ask to much from you but do you think you could provide a pull request (in consultation with our doc master @MrGeneration) to our admin documentation? We can/should cover the mapping, thumbprint, cert topics in the docs to be always up to date in one place.
If it’s not an option for you - could we turn it around and @MrGeneration could consult you when creating the documentation pull request?
I really like the follow up points you raised. Some are already on our issue tracker but currently I couldn’t find any However, I’ll have a second look in my next free time slot.
Yes I’d love to help generate some documentation around this. I already have detailed notes from the test deployment so I’ll grab some screenshots and put together a pull request over on github.
Thanks again for getting this feature ready!
Pull request is ready, let me know if you want any changes.
Pull request here:
Wow that was quick! Thank you very much I’ll need some time for QA, please bear with me. I’ll do it asap!
No rush on my end! I just wanted to make sure missing documentation isn’t a reason for this sweet feature to be delayed!
I didn’t compile down the docs in python to check the output formatting; I’m trusting githubs RST rendering is accurate. I hadn’t used RST prior to this effort, so I certainly wont be offended if there’s some things you want to change before accepting.
SAML authentication has landed in
develop and will be ready to install in about 20 minutes from now Thanks a ton for your support here and with the documentation (pull request) @carl2187 . This would have taken much longer if it weren’t for you. Looking forward to get stuff together again some day in the future
Any word on when SAML will land in a release :)?
PS: HUGE thanks again to @carl2187 <3
you all rock!
Got SAML working fully with keycloak but one question is it possible to disable login now and redirect directly to SAML :)?
We dont want users to be able to password reset or login with password for ISO27001 reasons
Nope, this is not possible
Can i submit it as a feature request
And Happy Holidays, thanks for all the amazing work on Zammad!!!
Sure, just create a new thread here:
It doesn’t make sense to have it on this thread, because the above feature is available and thus your feature request would get “lost” on the way. Also this allows other users to have a dedicated search fot it.
Sadly, I have to report that the documentation does not work with Keycloak 9.0.2.
With Client signatures enabled, I get a
(saml) Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, Fingerprint mismatch, while without Client signatures enabled I get a
Message from saml: invalid_ticket (Exceptions::UnprocessableEntity).
From my perspective, generic OAUTH as well as SAML should be a lot more stable. I’d be happy to help, if required.
Sadly, without proper OAUTH (incl. OIDC) or SAML, we can not even start to begin thinking about adopting Zammad.
Changing the code, as suggested in some solutions is not an option either, since we are talking of a Kubernetes install via Helm Chart.
So, what can be done here?
With Client signatures disabled, I get:
OneLogin::RubySaml::ValidationError, Found an unexpected number of Signature Element. SAML Response rejected