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

handnot2 · November 9, 2018, 3:12am

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.

darkmarmot · November 9, 2018, 4:01pm

Awesome, thanks!
I will check it out!

musicman3569 · November 30, 2018, 9:34pm

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!

handnot2 · December 1, 2018, 4:15am

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?

musicman3569 · December 3, 2018, 5:43pm

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!

codeangler · December 10, 2018, 11:11pm

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.

handnot2 · December 13, 2018, 5:38pm

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.

handnot2 · December 22, 2018, 4:17am

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.

handnot2 · December 31, 2018, 1:05am

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!

darkmarmot · January 4, 2019, 4:58pm

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

handnot2 · January 5, 2019, 6:15am

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

darkmarmot · January 7, 2019, 4:32pm

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!

handnot2 · January 7, 2019, 5:21pm

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

github.com

handnot2/samly/blob/01e52c95c7eb7f104160a33715defaf7c757f2fb/lib/samly/auth_handler.ex#L88


  #   error ->
  #     Logger.error("#{inspect error}")
  #     conn |> send_resp(500, "request_failed")
end


def send_signout_req(conn) do
  %IdpData{id: idp_id} = idp = conn.private[:samly_idp]
  %IdpData{esaml_idp_rec: idp_rec, esaml_sp_rec: sp_rec} = idp
  sp = ensure_sp_uris_set(sp_rec, conn)


  target_url = (conn.params["target_url"] || "/") |> URI.decode_www_form()
  assertion_key = get_session(conn, "samly_assertion_key")


  case State.get_assertion(conn, assertion_key) do
    %Assertion{idp_id: ^idp_id, authn: authn, subject: subject} ->
      session_index = Map.get(authn, "session_index", "")
      subject_rec = Subject.to_rec(subject)


      {idp_signout_url, req_xml_frag} =
        Helper.gen_idp_signout_req(sp, idp_rec, subject_rec, session_index)

darkmarmot · January 10, 2019, 2:45pm

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

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.

bournerj · January 21, 2019, 3:39pm

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

handnot2 · January 21, 2019, 8:33pm

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.

bournerj · January 22, 2019, 11:09am

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.

handnot2 · January 22, 2019, 3:34pm

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.

bournerj · January 22, 2019, 4:41pm

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

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

handnot2 · February 14, 2019, 2:16am

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)

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

SimpleSAMLphp IdP Docker Container

Published esaml v4.0.0

Samly v0.10.0

Samly v1.0.0-rc.0

Published `esaml` v4.0.0