handnot2 / samly Goto Github PK
View Code? Open in Web Editor NEWElixir Plug library to enable SAML 2.0 SP SSO in Phoenix/Plug applications.
License: MIT License
Elixir Plug library to enable SAML 2.0 SP SSO in Phoenix/Plug applications.
License: MIT License
Please why i'm getting this error. This happens while trying to process the SAMLReponse.
The SAMLEncoding, SAMLResponse and the RelayState were sent in the response.
Thanks.
Currently feeding Samly with metadata that describes federation (has <EntitiesDescriptor>
tag in root) is not possible. Can we support that?
Samly
supports Logout Post binding only. The esaml
generated SP metadata currently includes the Logout Redirect binding. This should be removed.
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
@handnot2: Is ADFS configured to encrypt the SAML assertion attributes?
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):
entity_id
needed to match its id.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.Here is an example SAML response (retrieved using the Firefox SAML-Tracer addon) with the details altered:
<Response ID="_85e7f245-f428-4d08-9ee4-d86aa3982d8f" Version="2.0" IssueInstant="2019-01-22T16:25:31.008Z" Destination="https://my-website/sso/sp/consume/idp_identifier" InResponseTo="id1548174206392814782111986" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
https://sts.windows.net/idp_identifier/
</Issuer>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</Status>
<Assertion ID="_33506e7a-3e12-45d4-894e-f5a7cbb092ef" IssueInstant="2019-01-22T16:25:30.992Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>
https://sts.windows.net/idp_identifier/
</Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#_33506e7a-3e12-45d4-894e-f5a7cbb092ef">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>
pxiPLd9eT4KLEy488Eef4J/6q5aZdleiiYzMcOxRbYI=
</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>
NnZha0PyVlvjA2TZ0bzfgVsrS4sjFRAphs0wjD8suDY7jKO51QJ026SG/lss1N/nDF3snyU6lSFaX4vQFlcI3G/8z/J+fVIOoAsuIHdW160qtBtqUYJU4zce3Z/HHZi09eOzdUqqBg7z/zY8mFPxEIZ7/bz1F9FjzDDaY/tfEfl2UedNVsYu0KaapNUiGB5oeyvhZ/I6ELJfHBjwyUY6BU0unHx7jGUW7TC6nf3UULb/ir2sr1R3rv7UgxbrWE7P6UHU0SYGRkyf73XuLIM/gSESN0fvZjwCncSye05tpFUEog+OkYnBlJxCHQtBLuVf6Xxo2/sCdaG4EMGZULj7zQ==
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
MIIC8DCCAdigAwIBAgIQLTJiSFda5qxGpkjtLwEBBjANBgkqhkpldo09d7ShADA0MTIwMAYDVQQDEylNaWNyb3NvZnQgQXp1cmUgRmVkZXJhdGVkIFNTTyBDZXJ0aWZpY2F0ZTAeFw0xOTAxMDkxNDAwMDJaFw0yMjAxMDkxNDAwMDJaMDQxMjAwBgNVBAMTKU1pY3Jvc29mdCBBenVyZSBGZWRlcmF0ZWQgU1NPIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAukESHqNsUOzhiwDjXgyvBFBpVhS2ZS6ePbW1SiB+18EnnZwSrxeO8beP8g43WSduqL0kxx5R+P5E+VAkH87IpXTm9HXRkhcwm8Xcp+6oTH7r7JqCvxgNP48AqqKSLeLj/vAjaUZa/AgT4b+9fj18ogcBYlCZ5iSLgyqB2FaBvli3L4P/c4zb35md7wQ7ez/Wl3ICcleleRjWvdOZzWHk7PwNJv7ZnnJ+SKVrWkSrRi0CQQQhXo4U0uM0u1paLAmopf9ASnOkvx2l5PIhvIJNulVJEHDVWgynyjy+RfvgRcUJgGcG7csvfjwIYZU4S1QJmNFUrlwU3dLV75sQRwZF1wIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAUlsUTF8MKW5FLqanNvddBhXSM8v7XxrhCrjd2u6v6G6OXSCkSphIJAymCcNCzDN6LLHOFNipSRg8V9jbFteuVOApECKPpgO0kRVHYqPAHyXqj8be9AwLJPEvYsHmujE9S6eamRiOJN3+MHEWUIUTJqaPNWezozVmvSHmpueoieQazZ7ZYOf/r5UH0q719+m5NuDYM2Ams38ec6mEly/kQezIrwruwfoWjSp1l+bdm+RmUE+VIGD8eXBQVmTCiA/50Et/gjmkx7SZgrETntBWjsnuf92wDaZKbrSeHnD1QZWs6/RDTTrRy6YbTB0dLX4gwU6TaJqDSrPv18KZ61LaC
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
Ogssl0DHDyVZDB3v9H+HEUMQCKHoBlOAkrw7SAX5Uw8=
</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="id1548174206328404782111986" NotOnOrAfter="2019-01-22T16:30:30.992Z" Recipient="https://my-website/sso/sp/consume/idp_identifier" />
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2019-01-22T16:20:30.992Z" NotOnOrAfter="2019-01-22T17:20:30.992Z">
<AudienceRestriction>
<Audience>
spn:be0cd693-414f-4369-b316-a89d948372ba
</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>
idp_identifier
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>
f9fhud3e-7e79-4eeb-b28b-a91351ada5f9
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
<AttributeValue>
Logged_In_User_Name
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>
https://sts.windows.net/idp_identifier/
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
<AttributeValue>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
<AttributeValue>
A_Role
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>
Logged_In_User_Name
</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
<AttributeValue>
[email protected]
</AttributeValue>
</Attribute>
<Attribute Name="Role Name">
<AttributeValue>
A_Role
</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2019-01-22T16:25:25.642Z" SessionIndex="_33506e7a-3e12-45d4-894e-f5a7cbb092ef">
<AuthnContext>
<AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</Response>
Thanks in advance.
We have the following part in an IdP metadata:
<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
When initiating a login with this IdP, the SP sends the following value:
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistenturn:oasis:names:tc:SAML:2.0:nameid-format:transienturn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedurn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
No nameid_format
was set in the IdP configuration.
I wasn't able to fully verify this with the specification, so I am not sure what the correct way to handle this is, but I suspect that just concatenating all 4 values is not correct?
@handnot2 please can you kindly update the name_format in the function below to use the nameid_format property provided in the idp configuration?
helper.ex
def gen_idp_signin_req(sp, idp_metadata) do
idp_signin_url = Esaml.esaml_idp_metadata(idp_metadata, :login_location)
# TODO: Expose an config
name_format = 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
xml_frag = :esaml_sp.generate_authn_request(idp_signin_url, sp, name_format)
{idp_signin_url, xml_frag}
end
Thanks for Samly! I would like to report a couple of issues, here's one.
I got Samly working in dev with Okta, but in prod it keeps giving me the "invalid_request unknown IdP" error even before reaching out to Okta.
Here's the relevant pieces.
My config:
config :samly, Samly.Provider,
idp_id_from: :path_segment,
service_providers: [
%{
id: "payments-admin",
certfile: "priv/keys/samly.crt",
keyfile: "priv/keys/samly.pem",
}
],
identity_providers: [
%{
id: "okta-payments-admin",
sp_id: "payments-admin",
base_url: "https://payments-admin.ourdomain.com/sso",
metadata_file: "config/saml/payments_admin_metadata.xml",
pre_session_create_pipeline: PaymentsWeb.Plugs.SamlyPipeline,
use_redirect_for_req: true,
}
]
The sign in URL looks like this:
https://payments-admin.ourdomain.com/sso/auth/signin/okta-payments-admin
Router:
scope "/sso", host: "payments-admin." do
forward "/", Samly.Router
end
Any ideas?
Hi and thanks for Samly, I've been trying to setup some tests using the d9eb636610e096f86f25d9a46f35a9facac35609a7591b3be3326e99a0484665
git ref
but even so samly continues requiring the keyfile
Configuration:
config :samly, Samly.Provider,
idp_id_from: :path_segment,
service_providers: [
%{
id: "alva-sp",
#entity_id: "urn:samly.howto:sp1",
certfile: "priv/keys/cert.crt"
}
],
identity_providers: [
%{
id: "nie-idp",
sp_id: "alva-sp",
base_url: "https://samly.howto:4443/sso",
metadata_file: "idp_metadata.xml",
pre_session_create_pipeline: SamlyHowtoWeb.Plugs.SamlyPipeline,
#use_redirect_for_req: true,
sign_requests: false,
sign_metadata: false,
#signed_assertion_in_resp: false,
#signed_envelopes_in_resp: false,
allow_idp_initiated_flow: false,
}
]
➜ samly_howto git:(master) ✗ bash ./runit.sh
Erlang/OTP 21 [erts-10.0] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]
[info] Application samly_howto exited: SamlyHowto.Application.start(:normal, []) returned an error: shutdown: failed to start child: SamlyHowtoWeb.Endpoint
** (EXIT) shutdown: failed to start child: Phoenix.Endpoint.Handler
** (EXIT) an exception was raised:
** (ArgumentError) could not start Cowboy adapter, the file /home/christian/go/src/github.com/chespinoza/samly_howto/_build/dev/lib/samly_howto/priv/keys/samly.pem required by SSL's :keyfile either does not exist, or the application does not have permission to access it
(plug) lib/plug/adapters/cowboy.ex:299: Plug.Adapters.Cowboy.fail/1
(plug) lib/plug/adapters/cowboy.ex:59: Plug.Adapters.Cowboy.args/4
(plug) lib/plug/adapters/cowboy.ex:120: Plug.Adapters.Cowboy.child_spec/4
(phoenix) lib/phoenix/endpoint/cowboy_handler.ex:81: Phoenix.Endpoint.CowboyHandler.child_spec/3
(phoenix) lib/phoenix/endpoint/handler.ex:33: anonymous fn/5 in Phoenix.Endpoint.Handler.init/1
(elixir) lib/enum.ex:1899: Enum."-reduce/3-lists^foldl/2-0-"/3
(phoenix) lib/phoenix/endpoint/handler.ex:31: Phoenix.Endpoint.Handler.init/1
(stdlib) supervisor.erl:295: :supervisor.init/1
(stdlib) gen_server.erl:374: :gen_server.init_it/2
(stdlib) gen_server.erl:342: :gen_server.init_it/6
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
** (Mix) Could not start application samly_howto: SamlyHowto.Application.start(:normal, []) returned an error: shutdown: failed to start child: SamlyHowtoWeb.Endpoint
** (EXIT) shutdown: failed to start child: Phoenix.Endpoint.Handler
** (EXIT) an exception was raised:
** (ArgumentError) could not start Cowboy adapter, the file /home/christian/go/src/github.com/chespinoza/samly_howto/_build/dev/lib/samly_howto/priv/keys/samly.pem required by SSL's :keyfile either does not exist, or the application does not have permission to access it
(plug) lib/plug/adapters/cowboy.ex:299: Plug.Adapters.Cowboy.fail/1
(plug) lib/plug/adapters/cowboy.ex:59: Plug.Adapters.Cowboy.args/4
(plug) lib/plug/adapters/cowboy.ex:120: Plug.Adapters.Cowboy.child_spec/4
(phoenix) lib/phoenix/endpoint/cowboy_handler.ex:81: Phoenix.Endpoint.CowboyHandler.child_spec/3
(phoenix) lib/phoenix/endpoint/handler.ex:33: anonymous fn/5 in Phoenix.Endpoint.Handler.init/1
(elixir) lib/enum.ex:1899: Enum."-reduce/3-lists^foldl/2-0-"/3
(phoenix) lib/phoenix/endpoint/handler.ex:31: Phoenix.Endpoint.Handler.init/1
(stdlib) supervisor.erl:295: :supervisor.init/1
(stdlib) gen_server.erl:374: :gen_server.init_it/2
(stdlib) gen_server.erl:342: :gen_server.init_it/6
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
Thanks in advance.
Hey,
Before trying to create a PR I want to ask if you would agree to extend the config by adding cert
, key
and metadata
keys in order to load them from environment variables, database etc.
I already took a look over the library and seems to be possible by modifying the Samly.SpData
and Samly.IdpData
modules.
Thanks,
OOTB Samly signs the SAML requests and responses. This is the desired behavior for production deployments. In case it is setup to work with IdPs that have this capability turned off, the following config options can be explicity set to false
for correct integration.
Enable following config options:
sign_requests
sign_metadata
signed_envelopes_in_idp_resp
signed_assertion_in_idp_resp
I’m receiving assertions containing:
<Assertion...>
<AttributeStatement>
...
<Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role">
<AttributeValue>ReadOnly</AttributeValue>
<AttributeValue>Recipient</AttributeValue>
...
</Attribute>
...
</AttributeStatement>
...
</Assertion>
My active assertion then looks like:
%Samly.Assertion{
....
attributes: %{
...
"role" => "ReadOnlyRecipient"
....
},
authn: %{
....
Should multiple attribute values currently be supported?
Thanks in advance
Check Issue: handnot2/esaml#1
Uptake this esaml fix.
Hi, I've successfully set up Samly with Okta and now trying to do the same with OneLogin, but the signin url generated by Samly is causing 500 Internal Server Errors on OneLogin. Was wondering if I was doing something wrong because there aren't 3rd party platform specific guides available for Samly.
Visiting http://myapp.com/sso/auth/signin/onelogin
redirects to this massive URL:
https://slab-dev.onelogin.com/trust/saml2/http-redirect/sso/729a675b-80b0-4bc5-bf60-79ad18fcd839?SAMLEncoding=urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE&SAMLRequest=lVfZkqNIsv2VtOxHLItdoLSuGgt2EEhiR7yxL2ITO%252Fr6q1RW1a3qmemZeZChcOK4nzjhuEf8%252BY%252B1rl7mpB%252BKtvn6in5BXv%252Fx7c8hqKvuHUxj3hjJbUqG8UXmvr4WMUrSJI4RFIYR5B4lMQRBiMcPe315uGmG9yfw6%252BvUN%252B9tMBTDexPUyfA%252BRu8m0NR37Avy3vXt2EZt9Svk7xHBMCT9%252BOD3%252BiIPw5TIzTAGzfj1FUMw5A3B3zDKQsl3kn4nMP%252F1xfmxmAf29YV7kC%252BaYHxa8nHshncYHqogfIuT%252BUvbJFWbFc2XqK3hsZ%252BGEf7gg8EfM9%252F6JC76JHrYhhamsH2wo8jwjUZC5I0II%252FItTHfIG7UPYpROo5jG968v4AdXtm2GqU56M%252BnnIkpsQ%252F3%252F8EFXfPmg8MHgI%252FCH%252B6GDo08I%252FIPU68v5u1ZM0cRFk%252F29TOHnpOFdsqzz2%252FlkWq%252BfO%252Fn%252BVK3%252F9gH%252BJeyf8K8v%252F4yHd7PIHkpNffJ9a%252BLhk%252FOD8rIsXxb8S9tn8Memw8gefsyJhyL74%252FUnNonlJm2fQzZo2qaIgqq4P7XXkjFv4xdQZW1fjHn9bxyjMIp8OH5L1ugtQonmj1f4d2r%252FtSOE%252BMHwrW775I9%252BCN6GPMDI3XeXRpImfdJEyYttyF9f%252F%252Fib7H7Ot%252FqgGdK2r4ffh%252F%252BRy29qJc382N0uid%252BGH0v6zue%252Fd%252FivVYL%252FmSNXZI%252F0%252Fx8le0jyx29CfXpxgmpKvsnbyl69LhM1Ed2K9dKfRqrRDegSwQ%252FFbJrKlxln96fklH19MvoV%252FDT8lP1z%252BJe8%252BbnPnwgXZe%252B17wl7ZGpv2FVw26O7OhFzis3s4ut3dYj2SnBgQ2ocpbq4dBkyR%252FkppQvvDF0qQkfys6ESCk0M0d04p4eGtcRa3SCdPZccCjyRadSLexvitVlMxBzrueLv990KMEO%252F7VuxWgYOcWFWPkbC0uTLoYyO1XE4OIcUC9SGyfIQ9ghusqAdHvEtGACBO1tRrz2yZOvqjIiwq9TZRK2NX4pYF3lRWVfTQE9OzYoBfz5SByUgoBE%252FxfOcrkg9x8bsbMzWzrjdDNhttB3nTENlzvm42asm5GvQlqNKHPWHDRFRESo3znWgA7W3BApo7ByIpiNeNm7gbhtU5zIXYmh5OcheeeZx7DQz14kt6zAoA%252FaEYvEZLZLLUh2UdgajH5GO25AsCNQWTPnpsMPHcb%252Fyoo3YupnaUmA4EJbR8HgkB2nHnXyX0%252Beuo8pMLE062sQImbzFLPFBBwRXBVCUOOK2Dvd4PHIULhri1QK%252B49zHc%252BsamJgWUnrAfW%252Bt04s8Uz59PlsMHgnkMLP2Auv1LtW5OjOlB4UxIwYPt01xEq5XatoQvE6FTBp2V4o6uG1NleWZDiJSteBV2HkZYifSKPX%252BokZKLWkckt9X%252Fjb4ZkZxQTkK9AGffdvorKZLu3gyAj%252Bf%252BL6Qc9rZjd7QBpoMobvqSnBcFFwmWSi6ewjdFMTdMfM843W9QsZwUkwYi5CvP9P5l%252Fz9SOlDsv1Mb49E9lwwBj8H7Ee3SB%252BFcky%252BabIseBzLAkRnWZ07OT7KtzJ9Ce7gyGTXW34txP2CMEAfBMAxi6YPC6tfOEd%252FpNWiOPadNzRAiwC1eRYssuVW11AUJl%252FSVr4EOpMdHQZEGuscc792sMBdB9%252FibY2RPzHZotqYMIbSNTPq53PlSqB94gaNsfM5xo1ZM%252FSFz55xOQ6M94uLDolJtiEeI%252BEdJMKCrCcOkJqlL9pdX45cHDxt1u82TQIrewfKp%252F%252BLBSrH0gx%252B4Zanb5kD%252BTFwjeHiktfozpsaA548mWVRHjwfdcHvQnGtfuFzePCxPvkw4vNp8ScNLJ%252FrWxbBFPd4LNKrwAHzM66msfgxD92VVOvv65NlVi7%252FqjkvAHBiQUaDj%252Fdsdnj85wFx83ehK9EJRwBX11s1yGzSlqm7bZHlVUXUm4rTCXRuUv9mJOMl74pSY%252FcCgu0qvRNRf6tYa6%252BzUoVZyj6eD%252FS6B0N7Mbs1F%252FjZpVJ2hVEIwgoqNByQLoGy8km%252Fs%252Fcpu3liR6GmH2IEjXSHdNpkvYcSJA27JS16lhXIc1rtHnXLycptZOKly%252FHD8WgNpbJTcKNcyvFEcoiH4nSb7oXbJp1ZvVYeX5aiUlDBHB2JVonscsARMtBVvRlk0EumykTgUhtq5KiocPFwYo6rtVgJMbVieeymVc6kmG1tKYwvCFafW6m3uSMe%252BdO9A8xonpOTXPCq%252F6jOXlLonRsXbZlW%252BgXpWs7yGuYKx5Kzt9riuHgRxEyPyldKxB7n774e5Q5R09a%252BgbTYEYPqkuNDrQXRVQKw2DEEysqTcDAg%252Fwiz1Qp0cZh1Bk4TtDzcBicCUkSd14XIr7PkOR5nRdTpsG%252BpIU8RlJRKwkWptCSak6L4coGQ5Frot2Mrn46gD83mKCAJ7zTcSWWRGCDYNcd9AORYauQI1Wc%252FysQtMKQdbk%252FAg81hmcKw05Gx27mhbqKiaemKcnBCLJdYy3JKAyG9Mm%252Bu2JUFWCdHUuHFqrBSWtDG1tQ7cL8KW0T1ZkrvY7JUt7sq8GmVwE598aawLpPmtoYDHfiItN9X%252BLjeDjN3XpKJs8tF0tDjzb2NamDqsv0oCTwA1r%252BoJc%252B85oFDMJOqz8BR9LNCOBM%252FPhohcZpiNFbKPAzho2yquWl0Tn0Pbh0tYDc%252FsQNrGgLBQ%252BxSJDwLpwot8RIONa7%252BSdxpbPxQjLFIpaoSEcAQilzKTuqkO6S7V%252Bcou3kY3fSJnJkTawY7K3Zikzm3s%252BNQdcl3iyzeiwu9nuBi6s4w37mJiLeWsnQwE83%252BTh24xMkF6WhYlUO4oIHFUN7fpeays%252FiOfyQJJfHyiqZVoCpzqh0UpjYqy429XMWd5VZnujJSK3fDWf%252FxecgB3BqpvNoeRiGm3Kd2tOak0xkQM%252B%252FQXU8UhbFgSnm9Q7eu6cPc5QRrpSF6mevAvHpA9LUlP3YCpWvsjeyqSwiXpAq7HiwfJKhd0I9y1kG8e%252FUClwy97ZBHodWZ2mQZLboBLhONUiLr2ZLN1b42aYEnlmKkJ%252FSaiopP3I8SbngSMLY6N%252BviTNxI%252Fhy0FoJlkJ%252BLVrSOKadkczQDFB7mLGIvSNHsGaIevey2ZyIKLIupYGV3hI4HrNo3DS7QRcXOB9zpaOi8tF24jRQR5vrOlk2rijt5RoRhvGLeZE1XaHmAh4wmI8z6OMT4pOVI23bNEis%252BtiHWjjlSBQ1M0OS0LfGZdaD8FBMF0CjEirLSRboC2ofhthPoJNq5DNWdhLD3UkS%252FCRsZlagW2QexrcvYkM7d1Zrv0Z1YRioGHpqUqmXfUD6iP5vtXxvoT%252BNni4V%252Fbb6%252FNecfN9zj4xIlc%252Be2KqLtRXgcm4Px39%252Bx0C%252Fo01LEb%252Blz6ntSB0UF4rhPhuF5Av%252Fne%252FO3%252FwM%253D&RelayState=XwFpVksFWW8CQfFiC-cOvKsiVBsYFsDc
which returns this 500 error on OneLogin:
Here's my config:
config :samly, Samly.Provider,
service_providers: [
%{
id: "myapp",
entity_id: "urn:myapp.com",
certfile: "config/dev/saml.crt",
keyfile: "config/dev/saml.pem",
}
],
identity_providers: [
%{
id: "onelogin",
sp_id: "myapp",
base_url: "https://myapp.com/sso",
metadata_file: "path/to/onelogin_idp.xml",
use_redirect_for_req: true,
allow_idp_initiated_flow: true,
allowed_target_urls: nil
}
]
OneLogin configs:
Hello,
Just curious if it was possible to use something like this with a federation, i.e. the AAF. However am finding it difficult to find information as required.
I don't care (or want) auto discovery, just something that will let me authenticate against specific IDPs that can be included easily in a Docker container. The only recommended solution is to use the Apache shib module, which is a lot of overhead for a docker container and gets confused easily with a Docker environment (been there done that).
As far as I can see however, the AAF requires end points and this plugin doesn't support them. So maybe that means this won't work as is?
In particular, it looks like "Assertion Consuming Service (Artifact)" is a required value, but samly only has a "Assertion Consuming Service (Post)".
There are a number of over end points, am hoping that they might be optional.
Regards
I can successfully connect samly with GSuite SAML app, but I receive a warning when starting a server:
[warn] [Samly] SLO Endpoint missing in [nil]
I'm not an expert with SAML-specification, but that is a metadata XML file that's downloadable from G Suite:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://accounts.google.com/o/saml2?idpid=C037nq81l" validUntil="2023-06-21T10:53:36.000Z">
<md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>xxx</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://accounts.google.com/o/saml2/idp?idpid=C037nq81l"/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://accounts.google.com/o/saml2/idp?idpid=C037nq81l"/>
</md:IDPSSODescriptor>
</md:EntityDescriptor>
Since it works fine, is this warning necessary?
Related issue: #36
The metadata generated by Samly for the SP is not valid in the eyes of testshib.org when registering a new service provider at this URL.
http://www.testshib.org/register.html
I have attached the metadata for my SP.
@handnot2 are you still maintaining this package or are you interested in handing it off?
The ability for a login to start from an IdP portal
Trying to add the domain to a ADFS IDP gives this error
Add-ADFSRelyingPartyTrust : ID6018: Digest verification failed for reference
CategoryInfo : InvalidData: (:) [Add-ADFSRelyingPartyTrust], CryptographicException
FullyQualifiedErrorId : ID6018: Digest verification failed for reference ...
FullyQualifiedErrorId : PS0132,Microsoft.IdentityServer.PowerShell.Commands.SetRelyingPartyTrustCommand
Set-ADFSRelyingPartyTrust : PS0132: No RelyingPartyTrust found with name ...
does the certificate of the SDP has to match the one of the HTTPS server it's running on? What could be the problem?
Hi, I'm having a problem with Shibboleth configuration and am a bit lost where to look for the solution. I have just set up samly_howto with both samly_simplesaml and samly_shibboleth. While there's no problem with SimpleSAML, I receive an empty attributes map in assertion from Shibboleth. I went through the steps described in this post: https://handnot2.github.io/blog/auth/saml-auth-for-phoenix
# config/path_segment_ssp_samly_config.exs
use Mix.Config
config :samly, Samly.State,
store: Samly.State.Session,
opts: [key: "my_samly_state_session_key"]
config :samly, Samly.Provider,
idp_id_from: :path_segment,
service_providers: [
%{
id: "sp1",
entity_id: "urn:samly.howto:samly_sp",
certfile: "priv/cert/samly_sp.pem",
keyfile: "priv/cert/samly_sp_key.pem",
contact_name: "Samly Howto SP1 Admin",
contact_email: "[email protected]",
org_name: "Samly Howto SP1",
org_displayname: "Samly Howto SP1 Displayname",
org_url: "https://samly.howto:4443"
}
],
identity_providers: [
%{
id: "idp",
sp_id: "sp1",
base_url: "https://samly.howto:4443/sso",
metadata_file: "idp_metadata.xml",
pre_session_create_pipeline: SamlyHowtoWeb.Plugs.SamlyPipeline,
allow_idp_initiated_flow: true,
use_redirect_for_req: false,
sign_requests: true,
sign_metadata: true,
signed_assertion_in_resp: true,
signed_envelopes_in_resp: true,
nameid_format: :transient
},
%{
id: "idp2",
sp_id: "sp1",
base_url: "https://samly.howto:4443/sso",
metadata_file: "idp2_metadata.xml",
pre_session_create_pipeline: SamlyHowtoWeb.Plugs.SamlyPipeline,
allow_idp_initiated_flow: true,
use_redirect_for_req: false,
sign_requests: true,
sign_metadata: true,
signed_assertion_in_resp: true,
signed_envelopes_in_resp: true,
nameid_format: :transient
}
]
idp
is Shibboleth's configuration, idp2
is SimpleSAML's configuration.
Visiting https://samly.howto:4443/?idp=idp2, "Sign In"
Everything works well. After clearing cookies and visiting https://samly.howto:4443?idp=idp
I receive empty attributes map. I left IO.inspect
here: https://github.com/handnot2/samly_howto/blob/master/lib/samly_howto_web/plugs/samly_pipeline.ex#L9 and that's the result:
When starting the server I do receive the [warn] [Samly] SLO Endpoint missing in ["idp_metadata.xml"]
error:
Can this be the reason? I have not changed any configuration in samly_shibboleth.
I would greatly appreciate any help that would help me understand how to configure Shibboleth to work with Samly. It's a great library that we use to host IdPs from Azure, G Suite, Auth0, and Okta. That's the first IdP where we hit the wall.
Update Here's a log from Shibboleth's start to the point where I'm back in samly_howto
.
Update2
I have a use-case where I'd like to access assertion.idp_id
inside my pre_session_create_pipeline
plug.
Presently idp_id
is set on the assertion after the pre_session_create_pipeline
plug is executed, so the plug sees %Assertion{idp_id: nil}
. Here is the relevant code.
I suggest that idp_id
be set on the Assertion
struct prior to it being passed to the pre_session_create_pipeline
.
Another way for me to accomplish this without code changes is to access conn.private[:samly_idp]
, which works fine, although the suggested change feels like a cleaner division between application code and library implementation details.
Thanks for a great package. I'm happy to submit a PR for this.
Some Shibboleth
IdP installations may have the SLO endpoint information commented out in their IdP metadata file. It would be better to generate a warning message at the time the IdP metadata file is loaded.
Currently Samly uses HTTP POST when sending requests to IdP. Support a config parameter to use HTTP redirect instead of POST.
config :samly, Samly.Provider,
use_redirect_for_idp_req: true
This should be an optional parameter. When not present or when not set to true
, Samly should use HTTP POST.
Hello,
The application using samly in dev mode is authenticating fine with Okta but when it redirects back to the app I am getting:
Plug.CSRFProtection.InvalidCSRFTokenError at POST /sso/auth/signin/okta_heimdall invalid CSRF (Cross Site Request Forgery) token, make sure all requests include a valid '_csrf_token' param or 'x-csrf-token' header
Does CSRF need to be disabled or is there a setting I am missing or possibly the redirect is wrong?
Thank you for the good library for SAML. While incorporating it I found that, although the Plug.Conn docs suggest that all response header keys be entered in lower case (ref: https://hexdocs.pm/plug/Plug.Conn.html#put_resp_header/3) and that an error will be thrown in tests if mixed case values are included, there are instances of calls to Plug.Conn.put_resp_header/3
which use mixed case and will fail in controller tests using helper functions like get
and post
.
If you are open to a PR against this I'll be glad to offer one addressing this.
Please i'm having issue getting this to work in my phoenix app. I have installed as stated in the readme details.
Below is what my config looks like
config :samly, Samly.Provider,
idp_id_from: :path_segment,
service_providers: [
%{
id: "entsp",
certfile: "priv/keys/samly.crt",
keyfile: "priv/keys/samly.pem"
}
],
identity_providers: [
%{
id: "entidp",
sp_id: "entsp",
metadata_file: "idp_metadata.xml"
}
]
While testing the login with the link http://localhost:4000/sso/auth/signin/entidp
, i got Argument error
After configuring Shibboleth correctly to work with my application which is an SP and using 0.8.1, I was able to see the Shibboleth login screen.
However after using 0.8.2 with the same working Shibboleth configuration, my SP was no longer recognised by Shibboleth. It appears to be a difference between the two AuthnRequest being sent from the SP. I have attached both for you to take a look at.
If sign_requests and sign_metadata is set to false then there should be no need to supply a certificate or key.
I'm trying to get IdP initiated logout to work with OneLogin which uses redirects to send the SLO request. Looking at the source code I can see that Samly only supports POST requests for logout, not GET:
Line 22 in 110d348
What would it take to get it to work with GET request/redirect? Would simply changing post
here to get
work? Also, while we're on the topic, is there something like the pre_session_create_pipeline
config for logout requests (so we can invalidate tokens or perform some other actions on a valid SLO request)?
Thanks!
The default multi IDP config for 0.8 works fine, however, when I modify to my custom server names, I am still using the docker image specified in samly_howto which uses SimpleSaml.
The host I am trying to run from is: federation.mannequin.localhost
I have modified the saml20-sp-remote.php to contain the following:
<?php
$metadata['http://federation.mannequin.localhost:4000/sso/sp/metadata'] = array(
'name' => 'samly_howto',
'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
'simplesaml.nameidattribute' => 'uid',
'signature.algorithm' => 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256',
'AssertionConsumerService' => 'http://federation.mannequin.localhost:4000/sso/sp/consume',
'SingleLogoutService' => array(
0 => array(
'Binding' => 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
'Location' => 'http://federation.mannequin.localhost:4000/sso/sp/logout',
),
),
'sign.logout' => true,
'validate.authnrequest' => true,
/* 'validate.logout' => true, */
'certificate' => 'sp/federation_mannequin_localhost/sp.crt',
);
Here are the development certificates I am using. Please note, that while the zip contains a file title mannequin_localhost.crt, I am renaming it when moving it to the SimpleSaml /setup/sp/federation_mannequin_localhost/ folder as sp.crt
Here is my config in my phoenix project:
config :samly, Samly.Provider,
idp_id_from: :subdomain,
service_providers: [
%{
id: "mannequin",
#entity_id: "urn:my-host:my-id",
certfile: "auth/mannequin_localhost.crt",
keyfile: "auth/mannequin_localhost.pem",
contact_name: "Samly Howto SP1 Admin",
contact_email: "[email protected]",
org_name: "Samly Howto SP1",
org_displayname: "Samly Howto SP1 Displayname",
org_url: "http://mannequin.localhost:4000"
},
],
identity_providers: [
%{
id: "federation",
sp_id: "mannequin",
base_url: "http://federation.mannequin.localhost:4000/sso",
metadata_file: "auth/idp_metadata.xml",
#pre_session_create_pipeline: SamlyHowtoWeb.Plugs.SamlyPipeline,
#use_redirect_for_req: true,
#sign_requests: true,
#sign_metadata: true,
#signed_assertion_in_resp: true,
#signed_envelopes_in_resp: true
}
]
Any ideas what might be going on? Here is the error received in SimpleSaml..
I have debugged this to make sure its picking up my SP metadata in SimpleSaml. But couldn't quite figure out where the unhandled exception was being thrown. I haven't changed any other SimpleSaml config.
Samly OOTB behavior is to use the metadata URI as the SP entity ID. Some of IdPs provide support for urn
style entity IDs.
Add a configuration option to support custom SP entityID:
config :samly, Samly.Provider,
entity_id: "urn:myhost-name:my-id"
Samly.State.Store.get_assetion's typespec is get_assertion(Conn.t(), assertion_key(), opts()) :: Assertion.t() | nil
But here we supply the function with the result of get_session(conn, "samly_assertion_key")
which will return nil if "samly_assertion_key"
key is not set.
I think this happens for the very first login attempt and obviously results in an exception.
So if a user has access in OKTA (for example) to use a given app (Samly SSO enabled), they successfully sign in and later their permissions to that app are revoked, it seems like the user remains logged in through Samly, it looks like notonorafter
could be used for automatically expiring the sessions, is this something we should take care of outside of Samly? or am I missing something?
Thanks!
Hey there - working through troubleshooting this error:
access_denied {{:badmatch, []}, [{:xmerl_dsig, :verify, 2, [file: '/app/deps/esaml/src/xmerl_dsig.erl', line: 200]}, {:esaml_sp, :"-validate_assertion/3-fun-3-", 3, [file: '/app/deps/esaml/src/esaml_sp.erl', line: 282]}, {:esaml_util, :threaduntil, 2, [file: '/app/deps/esaml/src/esaml_util.erl', line: 92]}, {Samly.Helper, :decode_idp_auth_resp, 3, [file: 'lib/samly/helper.ex', line: 72]}, {Samly.SPHandler, :consume_signin_response, 1, [file: 'lib/samly/sp_handler.ex', line: 37]}, {Samly.SPRouter, :"-dispatch/2-fun-0-", 4, [file: 'lib/plug/router.ex', line: 246]}, {:telemetry, :span, 3, [file: '/app/deps/telemetry/src/telemetry.erl', line: 321]}, {Samly.SPRouter, :dispatch, 2, [file: 'lib/plug/router.ex', line: 242]}]}
Anyone have any insight into this? I'm going to /sso/auth/signin/my_identity_provider
and it redirects to IDP where they get redirected back and I get the following error?
I see Mismatched or missing 'RelayState' in IdP responses to SP initiated requests will fail (with HTTP '403 access_denied')
and not sure why that would be.
I have recently upgraded my deps from:
{:phoenix, "~> 1.3.3"},
{:phoenix_pubsub, "~> 1.0"},
{:phoenix_ecto, "~> 3.2"},
{:postgrex, ">= 0.0.0"},
{:phoenix_html, "~> 2.6"},
{:phoenix_live_reload, "~> 1.0", only: :dev},
{:gettext, "~> 0.11"},
{:plug_cowboy, "~> 1.0"},
{:absinthe, "~> 1.4.2"},
{:absinthe_plug, "~> 1.4.0"},
{:absinthe_phoenix, "~> 1.4.0"},
{:absinthe_relay, "~> 1.4.0"},
{:distillery, "~> 0.10.1"},
{:samly, "~> 0.8"},
{:timex, "~> 3.1"},
{:guardian, "~> 1.0"},
{:comeonin, "~> 4.1"},
{:bcrypt_elixir, "~> 1.0"},
{:temp, "~> 0.4"},
{:xml_builder, "~> 2.0.0"}
to:
{:phoenix, "~> 1.4.11"},
{:phoenix_pubsub, "~> 1.1.2"},
{:phoenix_ecto, "~> 4.1.0"},
{:ecto_sql, "~> 3.2"},
{:postgrex, "~> 0.15.1"},
{:phoenix_html, "~> 2.13.3"},
{:phoenix_live_reload, "~> 1.2.1", only: :dev},
{:plug_cowboy, "~> 2.1.0"},
{:absinthe, "~> 1.4.16"},
{:absinthe_plug, "~> 1.4.7"},
{:absinthe_phoenix, "~> 1.4.4"},
{:absinthe_relay, "~> 1.4.6"},
{:distillery, "~> 2.1.1"},
{:samly, "~> 1.0.0"},
{:timex, "~> 3.6.1"},
{:guardian, "~> 1.2.1"},
{:comeonin, "~> 5.1.3"},
{:bcrypt_elixir, "~> 2.0.3"},
{:temp, "~> 0.4.7"},
{:gettext, "~> 0.11"},
{:jason, "~> 1.1.2"},
{:poison, "~> 4.0.1"},
{:xml_builder, "~> 2.1.2"}
and am now seeing the following ADFS error:
AADSTS750056: SAML message was not properly base64-encoded.
Is there anything obvious you can suggest?
Thanks
Richard
Include the metadata filename in error messages when there is an error in reading or parsing the file. With multiple IdP support, a generic error message is not helpful.
With the current code, it's not possible to use more than one identity provider in your application.
Currently the state is stored in ETS. Planning to provide a session based storage along with the ability to have custom storage providers. ETS support might be removed.
Are there any plans to support Cowboy 2.X? It would be really useful as a lot of libs for elixir require it now and it leads to a lot of dependency conflicts.
Related in the Esaml: handnot2/esaml#11
Provide built-in support for CSP as well as the ability to override it.
Referrer checks are not specific to Samly
. It is better to let a consuming application handle this.
wget http://samly.idp:8082/simplesaml/saml2/idp/metadata.php -O idp_metadata.xml
in the tutorial the link is outdated, and I am stuck at this point
I was able to get SSO working with Okta, but having an issue with Single Logout, always returning 403 Authn Failure "Invalid Signature".
Saml Trace
GET
<?xml version="1.0"?>
<samlp:LogoutRequest
Destination="https://dev-455970.oktapreview.com/app/heimdall_heimdall_3/exkga21ozaP0T2pcG0h7/slo/saml"
ID="id153704109584333124814146" IssueInstant="2018-09-15T19:52:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Reason="urn:oasis:names:tc:SAML:2.0:logout:user" Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#id153704109584333124814146">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>4tDSZaOzXbmXi3BCqaiYC2WY5V1wLyPuh5xmAdJK6mg=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>GPYcJ7VSenb/P43/bUYi/8dtLTVlGkHT88l7xB+Eea+zY2bOiUraPTqtbWavDvb0yd6qwdwWCDypNLS3CA/Z1d2LWriv9c23S002PjhxubnbFn0MolcDVWpY/kGnN2h6PJOJLXjHSFbnYAFvPejflHTGur11YJtg7lqrZJ2shxZoER2W1/uS2tj/iVhPIf+OyqHjAkOt2KfYlWDoIemiOwvMmz6uu84sp1wEvfYi8tW42GHHHgJFdSL9k9JdOhlDH0MlhUWF6rzm2DIfZJyRZMg5kgzQiRLAYs1ygGC6NkO2g5IQckWrej0KxyEBaXebwMD0w94xKp3iDivwl/mfudhRNCtIyMThtZw7qfT/PzuSH125MdY0krhWvZCXAZ1DR1fBhzw6/RoZFk/Eq7+iBV+GrRAcgBLv7BOaDUXGuFJIIp1g3TfYtxLRJuiC0rRMV8gEiKXiH0Rm9Wh8jw+pn8A/8/KMRVrcndpzQsla3MJ1BN7HRE5TzsL18SlAS2hMhb+Pj6JNBF6KSoEWZivqGfbwrspjzAg1Xx/ZCrBu7HkrF/+9bt+W9xAuQ6JzNHJFZxg9lufvQYBhvJOfQ3ea0wUCRsHkrb5eEDtndeQ4wPf+g9ncW62zDooQDXyYw0OMHY4IE3iNy8JJt+Up+IUB64tRDYbg6VVxM0Uu6nMSS9g=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDpDCCAoygAwIBAgIGAWXOODnmMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEUMBIGA1UECwwLU1NPUHJvdmlkZXIxEzARBgNVBAMMCmRldi00NTU5NzAxHDAaBgkqhkiG9w0BCQEWDWluZm9Ab2t0YS5jb20wHhcNMTgwOTEyMTQzNzM2WhcNMjgwOTEyMTQzODM1WjCBkjELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDTALBgNVBAoMBE9rdGExFDASBgNVBAsMC1NTT1Byb3ZpZGVyMRMwEQYDVQQDDApkZXYtNDU1OTcwMRwwGgYJKoZIhvcNAQkBFg1pbmZvQG9rdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlveqreKkBgHRsCbxLCYAyEWydeqzbzNZ9MWElnE89n/Ums2CpWBh9b9lFZlJXr1eb+07E3jKROZQuzPV8z6Ds2G7jDv92apXJ1so2SZ7DVdE4kC8Z11ujbMW+F3WWeGK+vASdGYkIbcpXdgy42Whi7MWqw8vwFIC4rxJ7HffwSpQvc87+tICDO2jn/iVupoqTQhjyKg0iuJV4vli5D7ne7n0E5sn3AE0R3hLn+88Ufm7MZD8AXVEdna8t8/kqGYVrol7yLYlOPp8u+pNd0bkAQ3lBRJb6f/kch8ommlywzv7lZA9+d02xaHd0G2x/KJt6xqVHTBazK5fdbCKgV7fXQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBvb5Raz1XYOSVV7scdOwSzhf0r0GOBl9V2YNmLD8gCID5VknJHBD+riI8vHu2UkIh39s2c+4LISTQ9Gu0KCcI2LU8nXz9Xy3oGMEgYEUz7ZwmcZGU/bMIANjfdyhJ1kURMG0vQcjNMVpAvqna+mb1idFTwjK7ArEgaOxh/XoCNIZ9t1tkZh69DX09nUYTn1G3RIbyGGZ/7GY2dfSJubuhZnvK528QaowvRG/zGHYbwUdwgbJIMTX2eR1jHKTi3L5xM/hED/fPkbF880fheumiR9AAS3OB71DdiUM3LMc8iaZkTd7PTXvfw7TeSM9rf62Caimx0DhBjJhsuI6PyXxC4</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Issuer>heimdall</saml:Issuer>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">[email protected]</saml:NameID>
<samlp:SessionIndex>id153704105052115878813602</samlp:SessionIndex>
</samlp:LogoutRequest>
POST https://localhost:4443/sso/sp/logout/okta_heimdall
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse Destination="https://localhost:4443/sso/sp/logout/okta_heimdall"
ID="id7678592447510182044070111" InResponseTo="id153704109584333124814146"
IssueInstant="2018-09-15T19:52:31.109Z" Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://www.okta.com/exkga21ozaP0T2pcG0h7</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#id7678592447510182044070111">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>283rIuOaM+hL31Nl+hVcevNirAseiSClDjwpVCWAXtQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>ebcTux5oIGBdJdOiPsrTN9i3W2MZ9PO4HSJQANdXG7ofa3EvcYwwfXzMsqNTrvPOikAYZnKbqgJofmxBMbsD04XmmyxYtrjnop3jW45hHsEMVp44rC2I9PFt0Y+zUh2ua77wjN3c5ozXR2vKzGWZkmpK3TGvpbsMsO1ODCf5DwogheCYwInpoO+gA69xhzgedN0wDU3PPSOhRcROLuhAJUxD8F5nPFQh3sB7ohbgi1mgAjmLjG0M6ogDP2pcN1rdQH/esPFKYwUh8rffL62KGtCgVbSQ53N6cUeCi8iWUfL5o0DHUP8SKVbc1wUhjk/+mK+geh2NCooHgWus6j1HEQ==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDpDCCAoygAwIBAgIGAWXOODnmMA0GCSqGSIb3DQEBCwUAMIGSMQswCQYDVQQGEwJVUzETMBEG
A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU
MBIGA1UECwwLU1NPUHJvdmlkZXIxEzARBgNVBAMMCmRldi00NTU5NzAxHDAaBgkqhkiG9w0BCQEW
DWluZm9Ab2t0YS5jb20wHhcNMTgwOTEyMTQzNzM2WhcNMjgwOTEyMTQzODM1WjCBkjELMAkGA1UE
BhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xDTALBgNV
BAoMBE9rdGExFDASBgNVBAsMC1NTT1Byb3ZpZGVyMRMwEQYDVQQDDApkZXYtNDU1OTcwMRwwGgYJ
KoZIhvcNAQkBFg1pbmZvQG9rdGEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
lveqreKkBgHRsCbxLCYAyEWydeqzbzNZ9MWElnE89n/Ums2CpWBh9b9lFZlJXr1eb+07E3jKROZQ
uzPV8z6Ds2G7jDv92apXJ1so2SZ7DVdE4kC8Z11ujbMW+F3WWeGK+vASdGYkIbcpXdgy42Whi7MW
qw8vwFIC4rxJ7HffwSpQvc87+tICDO2jn/iVupoqTQhjyKg0iuJV4vli5D7ne7n0E5sn3AE0R3hL
n+88Ufm7MZD8AXVEdna8t8/kqGYVrol7yLYlOPp8u+pNd0bkAQ3lBRJb6f/kch8ommlywzv7lZA9
+d02xaHd0G2x/KJt6xqVHTBazK5fdbCKgV7fXQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBvb5Ra
z1XYOSVV7scdOwSzhf0r0GOBl9V2YNmLD8gCID5VknJHBD+riI8vHu2UkIh39s2c+4LISTQ9Gu0K
CcI2LU8nXz9Xy3oGMEgYEUz7ZwmcZGU/bMIANjfdyhJ1kURMG0vQcjNMVpAvqna+mb1idFTwjK7A
rEgaOxh/XoCNIZ9t1tkZh69DX09nUYTn1G3RIbyGGZ/7GY2dfSJubuhZnvK528QaowvRG/zGHYbw
UdwgbJIMTX2eR1jHKTi3L5xM/hED/fPkbF880fheumiR9AAS3OB71DdiUM3LMc8iaZkTd7PTXvfw
7TeSM9rf62Caimx0DhBjJhsuI6PyXxC4</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"><saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed"/></saml2p:Status>
</saml2p:LogoutResponse>
Is there a recommended way to add identity providers at runtime? Currently we are doing Application.put_env(:samly, :identity_providers, identity_providers)
and generating identity_providers
from IdpData.load_providers/1
which doesn't feel like the cleanest since it has to re-generate existing identity providers.
Happy to contribute a PR if there is interest supporting an API to add a new identity provider at runtime. The use case for us is we allow users to integrate their Okta organization so different users Okta accounts ex. company1.okta.com
and company2.okta.com
which would correspond to company1.slab.com
and company2.slab.com
on our end. These would have different metadata XML files that we would add during runtime.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.