silvagustin
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.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming












Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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_respandsigned_envelopes_in_resptofalseto skip that checkis the response signed in the way that
esamlexpects? The comment above:xmerl_dsig.verifysays that an unexpected input would produce exactly thebadmatchseen in your error message…https://github.com/arekinath/esaml/blob/bf52dcb449184dc94e4fb1ff8820b08cc1ceab09/src/xmerl_dsig.erl#L156-L164
voltone
I have successfully integrated Samly with Azure AD using
signed_assertion_in_resp: trueandsigned_envelopes_in_resp: falsesilvagustin
Hey guys, thanks for your responses.
This is my current configuration for Samly:
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.
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.
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.
silvagustin
I’m using self signed certificates because I’m on development. Also, it shouldn’t matter because
signed_assertion_in_respsetting isfalse. Or should I get some kind of real certificate for development?About
entity_id: "idp1", it’s truly theEntity IDfrom the application in Azure AD (see the screenshot from Azure AD config at the top). Do you think that it’s something else?Cheers.
kokolegorille
Mine from Azure looks like this…
with x being in hexa…
It’s something I could get from idp_metadata file.
silvagustin
If I use the
EntityIdfrom themetadata.xmlfile I get the following error:Not sure why this happens because my app is indeed on the default directory:
This was my config:
With
entity_id: "idp1"config I get{:error, :invalid_relay_state}. I did some debugging and that comes fromSamly.SPHandlervalidate_authresp/3where allrd_in_session,idp_id_in_sessionandurl_in_sessionarenil.Not sure how to proceed nor try next
Cheers.
scoop
Hey, did you manage to finally integrate
samlywith Azure AD?I’m about to do this now.
Kind regards

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.