silvagustin

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

Cheers.

12 comments

#saml #azure-active-directory #sso #samly

2 1483 12

2024-07-15 20:43:41 UTC

First 10 of 12 Posts!

al2o3cr

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…

https://github.com/arekinath/esaml/blob/bf52dcb449184dc94e4fb1ff8820b08cc1ceab09/src/xmerl_dsig.erl#L156-L164

Post #1

voltone

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

Post #2

silvagustin

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 .

Cheers.

Post #3

sheharyarn

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.

Post #4

kokolegorille

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.

Post #5

silvagustin

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.

Post #6

kokolegorille

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.

Post #7

silvagustin

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

Cheers.

Post #8

scoop

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

I’m about to do this now.

Kind regards

Post #9

silvagustin

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.

Post #10

Last Post!

adamverb

fyi you can set up Samly SSO with Azure AD SSO (Microsoft Entra). however i first set up locally got it working with simplesamlphp, then moved to staging environment and got it working with simplesamlphp as its just easier for me as i’ve used it before. then after i got that working fine i set up Azure AD which is Entra now. Took me roughly 2 days to get it fully working with signing/encryption at that point. i suggest doing this yourself instead of with a client as lots of iteration was needed for my goals, mostly due to a single Samly setting.

i started with this. i wanted store to be session instead of ETS and i used a custom key, you can use the key to delete the session to help logout (default key is “samly_assertion”)

  config :samly, Samly.State,
    store: Samly.State.Session,
    opts: [key: "custom_key_here"]

can use key like this to delete from session

  |> delete_session(:samly_assertion)
  |> Guardian.Plug.sign_out()

as for rest of samly settings pretty simple honestly cept for signed_envelopes_in_resp if you want to use encryption on Azure, that needs to be false or you get :bad_digest error. but here is what i have, most are env vars for me but i’ll change for here to make simpler.

  config :samly, Samly.Provider,
    idp_id_from: :path_segment,
    service_providers: [
      %{
        id: "sp1",
        entity_id: "urn:myapp.com:samly_sp",
        certfile: "/app/saml_sp_cert_file.pem",
        keyfile: "/app/saml_sp_key_file.pem",
        contact_name: "Administrator",
        contact_email: "myemail@mycompany.com,
        org_name: "mycompany",
        org_displayname: "mycompany",
        org_url: "https://myapp.com"
      }
    ],
    identity_providers: [
      %{
        id: "idp1",
        sp_id: "sp1",
        base_url: "https://myapp.com/sso",
        metadata_file: "/app/lib/my_app-1.0.0/priv/metadata/idp_metadata_azure_testing.xml",
        allow_idp_initiated_flow: false,
        use_redirect_for_req: false,
        sign_requests: true,
        sign_metadata: true,
        signed_assertion_in_resp: true,
        signed_envelopes_in_resp: false
      }
    ]

on the Azure (Entra) side wanna be here https://entra.microsoft.com/.
Identifier (Entity ID) = entity_id from sp1
Reply URL (Assertion Consumer Service URL) = https://myapp.com/sso/sp/consume/idp1

then in SAML Certificates set Signing Option to sign both response and assertion. this is how i wanted it, there is no option for neither, so not sure if that’s possible or not.

then in Token encryption upload your public cert if you want to enable encryption, if the status is Active then encryption is on if its Inactive then encryption is off. on the Samly side there is no turning encryption on/off thats just on the Entra side by this Active/Inactive cert.

NOTE: Obviously change anything you want also change all my app/company specific stuff.
NOTE2: There are a few more IDP settings which i don’t have here since i didn’t need them, but check out GitHub - dropbox/samly: Elixir Plug library to enable SAML 2.0 SP SSO in Phoenix/Plug applications. · GitHub for them all.
NOTE3: I left out some minor stuff like attribute claims and code implementation for logout/in as that should be pretty straight forward, if your attempting this.

Post #12