How to setup Azure AD SSO using Samly?

Hi everyone.

I’m trying to add Azure AD SSO to an app I’m working on and when I try to start the login process I’m getting the following error:

Just in case, it’s my first time working with SAML, Azure AD and SSO.

My config/dev.exs file has the bare minimum settings in order to make it work asap and then I’ll add the optional stuff:

config :samly, Samly.Provider,
  idp_id_from: :path_segment,
  service_providers: [
    %{
      id: "sp1",
      entity_id: "idp1",
      # certfile: "priv/cert/samly_sp.pem",
      # keyfile: "priv/cert/samly_sp.pem"      
    }
  ],
  identity_providers: [
    %{
      id: "idp1",
      sp_id: "sp1",
      base_url: "http://localhost:4000/sso",
      metadata_file: "idps-metadata/idp1-metadata.xml",
      pre_session_create_pipeline: MySamlyPipeline,      
      sign_requests: false,
      sign_metadata: false      
    }
  ]

The MySamlyPipeline plug is the same as the one shown in the docs:

defmodule MySamlyPipeline do
  use Plug.Builder
  alias Samly.{Assertion}

  plug :compute_attributes
  plug :jit_provision_user

  def compute_attributes(conn, _opts) do
    assertion = conn.private[:samly_assertion]

    IO.inspect(assertion, label: "ASSERTION")

    # This assertion has the idp_id
    # %Assertion{idp_id: idp_id} = assertion

    first_name = Map.get(assertion.attributes, "first_name")
    last_name  = Map.get(assertion.attributes, "last_name")

    computed = %{"full_name" => "#{first_name} #{last_name}"}

    assertion = %Assertion{assertion | computed: computed}

    conn
    |>  put_private(:samly_assertion, assertion)

    # If you have an error condition:
    # conn
    # |>  send_resp(404, "attribute mapping failed")
    # |>  halt()
  end

  def jit_provision_user(conn, _opts) do
    # your user creation here ...
    conn
  end
end

Finally, my Enterprise Application in Azure has the following configs:

I’ve read the docs a few times and there are no posts about how to set up Azure AD using Samly. Also, I’ve inspected the code from the samly_howto but I couldn’t solve it neither.

I’m not sure what I’m doing wrong. I’m pretty sure it has to be some misconfiguration.

Any help would be appreciated :slight_smile:

Cheers.

2 Likes

It’s hard to be 100% sure without a stacktrace (please copy the text and paste it, if possible), but the fragment that’s visible in the screenshot suggests that Samly is attempting to verify a signature on the response.

There are two easy possibilities:

  • is the response signed at all? You could try setting signed_assertion_in_resp and signed_envelopes_in_resp to false to skip that check

  • is the response signed in the way that esaml expects? The comment above :xmerl_dsig.verify says that an unexpected input would produce exactly the badmatch seen in your error message…

I have successfully integrated Samly with Azure AD using signed_assertion_in_resp: true and signed_envelopes_in_resp: false

2 Likes

Hey guys, thanks for your responses.

This is my current configuration for Samly:

config :samly, Samly.Provider,
  idp_id_from: :path_segment,
  service_providers: [
    %{
      id: "sp1",
      entity_id: "idp1",
      certfile: "priv/cert/selfsigned.pem",
      keyfile: "priv/cert/selfsigned_key.pem"
    }
  ],
  identity_providers: [
    %{
      id: "idp1",
      sp_id: "sp1",
      base_url: "https://localhost:4001/sso",
      metadata_file: "idps-metadata/idp1-metadata.xml",
      pre_session_create_pipeline: MySamlyPipeline,
      signed_assertion_in_resp: false, # comment this line only if certfile is not selfsigned
      signed_envelopes_in_resp: false,
      allow_idp_initiated_flow: true
      # allowed_target_urls: ["https://localhost:4001"], # default: []; not sure if we need it
    }
  ]

I’ve managed to make it work by starting the SAML workflow from the Identity Provider (Azure AD). Here’s a demo:

https://drive.google.com/file/d/1ywiaErm0T_rmV-HhTXipvMHpk_yZPlBa/view?usp=sharing

This is the output I got from the SAML-tracer Chrome extension:

Unfortunately, I couldn’t make it work from the Service Provider which in my case is a Phoenix app running locally. Here’s a demo:

https://drive.google.com/drive/folders/14C3boxqH_8s2Fq3_e8YeM6n_RKcFANve

Again, this is the output I got from the SAML-tracer Chrome extension:

And here’s the server output:

My SAML configuration in Azure AD is still the same as I shown previously. I’m pretty sure that it has to do with some misconfiguration I’m doing wrong.

Also, I found two Github issues which I believe are related to this:

Still, neither one of them helped me to solved my problem.

Any help would be appreciated :grimacing:.

Cheers.

2 Likes

It’s really hard debugging samly issues. I was able to debug it by forking samly and putting logs in a bunch of places to try to figure out what was going on. I would recommend doing the same because without more information it’s really hard to tell what the issue might be.

2 Likes

This does not look good… it should match an Id coming from Azure.

Also, using self signed certificates might not work…

It’s a painful to make it work, but it’s related to bad config.

I’m using self signed certificates because I’m on development. Also, it shouldn’t matter because signed_assertion_in_resp setting is false. Or should I get some kind of real certificate for development?

About entity_id: "idp1", it’s truly the Entity ID from the application in Azure AD (see the screenshot from Azure AD config at the top). Do you think that it’s something else?

Cheers.

Mine from Azure looks like this…

spn:xxxxxxx-xxxx-xxxx-xxxxxx

with x being in hexa…

It’s something I could get from idp_metadata file.

If I use the EntityId from the metadata.xml file I get the following error:

AADSTS700016: Application with identifier '86c87751-faf3-4735-ac34-762b9769c467' was not found in the directory 'Default Directory'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

Not sure why this happens because my app is indeed on the default directory:

This was my config:

config :samly, Samly.Provider,
  idp_id_from: :path_segment,
  service_providers: [
    %{
      id: "sp1",
      entity_id: "86c87751-faf3-4735-ac34-762b9769c467",
      certfile: "priv/cert/selfsigned.pem",
      keyfile: "priv/cert/selfsigned_key.pem"
    }
  ],
  identity_providers: [
    %{
      id: "idp1",
      sp_id: "sp1",
      base_url: "https://localhost:4001/sso",
      metadata_file: "idps-metadata/idp1-metadata.xml",
      pre_session_create_pipeline: MySamlyPipeline,
      signed_assertion_in_resp: false,
      signed_envelopes_in_resp: false
    }
  ]

With entity_id: "idp1" config I get {:error, :invalid_relay_state}. I did some debugging and that comes from Samly.SPHandlervalidate_authresp/3 where all rd_in_session, idp_id_in_session and url_in_session are nil.

Not sure how to proceed nor try next :confused:

Cheers.

1 Like

Hey, did you manage to finally integrate samly with Azure AD?

I’m about to do this now.

Kind regards
:otter:

Hello scoop.

I’m sorry but I didn’t manage to solve it. Also, I’m no longer working on that because I moved to another company.

Cheers,
Agus.

1 Like

Thanks!

I’ll make sure to post any insights here for the community :slightly_smiling_face:

1 Like