Awesome, thanks!
I will check it out! 
darkmarmot
musicman3569
Sorry if I’m missing something simple, and I’ve searched for existing topics on Samly and Phoenix 1.4, but I’m getting errors with the instructions to set this up. I am currently on:
- Elixir 1.7.4 (compiled with Erlang/OTP 21)
- Erlang/OTP 21
- Windows 10 Pro x64 (version 1803)
And my Phoenix app’s deps are:
[
{:phoenix, “~> 1.4.0”},
{:phoenix_pubsub, “~> 1.1”},
{:phoenix_ecto, “~> 4.0”},
{:ecto_sql, “~> 3.0”},
{:postgrex, “>= 0.0.0”},
{:phoenix_html, “~> 2.11”},
{:phoenix_live_reload, “~> 1.2”, only: :dev},
{:gettext, “~> 0.11”},
{:jason, “~> 1.0”},
{:plug_cowboy, “~> 2.0”},
{:samly, “~> 0.9”}
]
When I run mix deps.get, I get the output:
?[4mFailed to use “cowboy” (version 2.6.1) because?[0m
?[1mesaml (versions 3.4.0 to 3.6.1)?[0m requires ?[31m1.1.2?[0m
?[1mplug_cowboy (version 2.0.0)?[0m requires ?[32m~> 2.5?[0m
?[1mmix.lock?[0m specifies ?[32m2.6.1?[0m
?[0m
** (Mix) Hex dependency resolution failed, change the version requirements of your dependencies or unlock them (by using mix deps.update or mix deps.unlock). If you are unable to resolve the conflicts you can try overriding with {:dependency, “~> 1.0”, override: true}
I am brand-new to Phoenix so it might just be me, but it looks like there are version issues with plug_cowboy? However, if I try to add “override: true” I still get the error. From what I can tell the problem is specifically with the dependencies of esaml, but I’m not sure. I’m happy to contribute to this if I can get pointed in the right direction. Thoughts? Thanks in advance!
0
handnot2
Haven’t checked Samly with Phoenix 1.4 and cowboy 2.0. Not sure if there are any compatibility problems. Please open an issue in the Samly Repo.
Can you check it out with Phoenix 1.3 and cowboy/plug_cowboy 1.x?
0
musicman3569
Thanks so much for the quick response. After struggling to get it to resolve for Phoenix 1.4, for now I am going to instead look at Gravitee.IO (which uses OpenID Connect) since it looks like it has an up-to-date, officially supported package. If I do ultimately decide to go back to SAML I’ll let you know what I find. Cheers!
0
codeangler
Does SAMLY care what format the certificate files are in?
I’m trying to integrate with ADFS, I’m getting some errors.
ID6013: The signature verification failed.
ID6018: Digest verification failed for reference ‘#id1543437817381650518114’.
verifying w/ SSL Certificate Decoder the .crt is working
A potential culprit is that UNIX build step using OpenSSL is created a Unix style line breaks that Powershell is not reading correctly.
One thought I’ve had was to generate .pfx from .pem.
However as I’m in the dark on much of this, I am only guessing that it might assist the blocker I have.
0
handnot2
If you think the unix generated file with line endings is causing the issue, I suggest trying PuTTYgen on windows to generate the key and certificate files.
Hopefully someone one the forum pitches in to help with generating self signed cert and importing the cert in ADFS.
0
handnot2
Published esaml v4.0.0
esaml is the Erlang SAML library that Samly uses. There are no functional changes in this release. esaml in this release is migrated to use Cowboy 2.
Hoping to release Samly v1.0.0 soon with this version of esaml.
In the meantime, you should be able to use this new esaml lib along with the current Samly v0.9.x and phoenix 1.4 with mix dependency override.
If you want to continue to use
Samlyv0.9.x withphoenix1.3 andCowboy1.x, you need to useesamlv3.x.x.
0
handnot2
Samly v0.10.0
Highlights:
- Phoenix 1.4/Cowboy 2.x support (check
README.mdif you need to continue working with Phoenix 1.3) - Customizable state store - includes
Samly.State.ETSandSamly.State.SessionOOTB
There are some formatting corrections and an additional bug fix as well in this version. Check out CHANGELOG.md
Getting closer to v1.0 release!
0
darkmarmot
Awesome, thanks for this!!!
We’ve been testing it on Phoenix 1.4 and have our login working – but logout is throwing an error.
In login – the conn params includes idp_id_seg which seems to be pulled from glob and it looks correct.
But in logout, our idp_id_seg is missing and doesn’t seem to be extracted from the glob path_params (which are what we’d expect, with the idp in the 2nd position).
We end up getting:
invalid_request unknown IdP
Any ideas what might cause logout to fail when login works?
Thanks so much for your work on this! Really helping to get Elixir into enterprise environments
Scott
0
handnot2
I am assuming you have set/configured the SingleLogout URL correct in your IdP.
Can you install the saml-tracer Firefox add-on and check the request/response communication betweeen your app/samly and your IdP? Do you see a successful LogoutResponse?
What IdP are you using?
It is possible that there might be content-security-policy in play here. Quite possibly you are not getting the cookie, resulting in error. Is there an embedded frame is involved in the logout flow? Check the 3rd party cookie browser setting as well.
Make sure that the LogoutResponse is sent from IdP to Samly by HTTP-POST binding. Samly does not support the redirect binding for security reasons. (There is a github issue for this - to remove the redirect binding from the generated SP metadata.)
0