Samly - Add SAML SSO to your Phoenix application (now with multiple identity provider support)

samly

#21
SimpleSAMLphp IdP Docker Container

samly_simplesaml (v0.3)

Moved up to the latest SimpleSAMLphp release Version 1.16.2. Updated the parameters and config templates to match this version of SimpleSAMLphp. You will have to rebuild the docker image. Make sure to update to the latest version of docker-ce and docker-compose.

./build.sh
docker-compose up -d
sleep 5
docker-compose down
docker-compose up -d

It should work without any config errors with this update.


#22

Awesome, thanks!
I will check it out! :slight_smile:


#23

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!


#24

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?


#25

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!


#26

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/ https://www.sslchecker.com/certdecoder 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.


#27

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.


#28

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 Samly v0.9.x with phoenix 1.3 and Cowboy 1.x, you need to use esaml v3.x.x.


#29

Samly v0.10.0

Highlights:

  • Phoenix 1.4/Cowboy 2.x support (check README.md if you need to continue working with Phoenix 1.3)
  • Customizable state store - includes Samly.State.ETS and Samly.State.Session OOTB

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!


#30

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 :slight_smile:
Scott


#31

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.)


#32

We are ultimately trying to use PingFederate as our IDP (to get ActiveDirectory auth).

For the logout testing locally right now, we are just using your PHP docker IDP. We get
a successful logout – but then don’t redirect correctly it seems.

Will test more with Firefox and see if I can find anything useful there, thanks!

One other strangeness as a shot in the dark – our local Samly setup seems to work for login – using your PHP docker, but when we put things in production we get ERR_SPDY_PROTOCOL_ERROR right off the bat.

We think possibly our umbrella project docker deployment is not getting the right files for SAMLY because the paths from config at compile might not match prod…

Thanks for the assistance! I’ll report back with anything else we figure out! :slight_smile:


#33

Are you setting the target_url query param when initiating the logout request?


#34

Just wanted to note that we finally have things working with Samly against PingFederate! :slight_smile:

Our biggest issue turned out to be case-sensitive proxy-header stuff (thanks for merging our PR!!!)

Some of the team is even looking to add some config and testing stuff to your library now if you’re amenable to it.

Thanks again!
Scott S.


#35

I’m currently trying to use Samly with ADFS, everything going well up until the response is verified - where I start seeing a :badmatch error:

access_denied {:invalid_request, "{:error, {{:badmatch, []}, [{:xmerl_dsig, :verify, 2, [file: '/PHX/deps/esaml/src/xmerl_dsig.erl', line: 168]}...

Line 168 in xmerl_dsig.erl is:

[#xmlAttribute{value = SignatureMethodAlgorithm}] = xmerl_xpath:string("ds:Signature/ds:SignedInfo/ds:SignatureMethod/@Algorithm", Element, [{namespace, DsNs}]),

I’ve added some logging in there to confirm that Element exists and appears to contain what is being asked of it.

This error comes with config for the IDP like:

{
  ...
  sign_requests: true,
  sign_metadata: true
  signed_assertion_in_resp: true,
  signed_envelopes_in_resp: true
  ...
}

I’ve tried setting the latter two to false individually and together and get different errors.

I can see the SAML response when it comes back and verify that it’s what I’m expecting (via an online SAML decoder).

Versions are:

phoenix: 1.3.4
esaml: 3.6.1
samly: 0.9.3

Any ideas or anything to try?

Thanks in advance!

Rich


#36

Is ADFS configured to encrypt the SAML assertion attributes? Samly doesn’t support encrypted assertion attributes yet. There is a pull request in the esaml lib for this ADFS support. Haven’t yet had the time to check out and merge it in. Will need to uptake that change in Samly. Hopefully in a week or so.

Don’t know if you have the ability to turn off assertion encryption (still keep signing). If you do, you try that option.


#37

Thanks for the quick response!

No, ADFS is only set to sign the assertion - there is no option to encrypt.

I tried again just to confirm with signed_assertions_in_resp: false and got the same error.

Maybe there is something else going on with ADFS?

I did have to enter a couple of the config settings in what seemed to be the wrong place in order to get things working - for example (which might help with the integration if it hasn’t already been taken care of):

  • SP’s entity_id needed to match its id.
  • IDP’s base_url needed to be set to http://my_website.com/sso - this may just be my misunderstanding but I assumed I needed the .../sso URL in the SP config.

#38

Can you open an issue in Samly github repo? Please use firefox saml-tracer extension to get the SAML XML reponse and include in the issue. You can cut out the parts of the XML that you don’t want to be public - such as your URLs or assertions from the XML before including in the issue. That would be helpful to figure out what the problem might be.


#39

I’ve done that - thanks again for your help.

For reference, the issue is at https://github.com/handnot2/samly/issues/42.


#40

Samly v1.0.0-rc.0

Try this release candidate and provide your feedback. Please report any issues in github so that we can correct them and get v1.0.0 out. A simple one line feedback would be appreciated even when you don’t find any issues.

Highlights:

  • content-security-policy response header is enabled. This covers only the samly related routes.
  • Ability to override the nameid_format in the SAML authentication request in config.
  • Uptake esaml v4.2/v3.7 - bringing in automatic support for encrypted SAML assertions. Includes support for aes128-gcm, aes128-cbc and aes256-cbc data encryption algorithms and rsa-oaep-mgf1p key encryption algorithm.
  • Both Phoenix 1.4 and Phoenix 1.3 are supported. For Phoenix 1.3 you need to do esaml v3.7 dependency override in mix.exs (check README.md)