handnot2 / samly Goto Github PK

View Code? Open in Web Editor NEW

126.0 126.0 92.0 142 KB

Elixir Plug library to enable SAML 2.0 SP SSO in Phoenix/Plug applications.

License: MIT License

Elixir 100.00%

plug-pipeline saml-assertion saml2-sp-sso

samly's People

Contributors

Stargazers

Watchers

Forkers

bluebeanstudios peterox bundacia chanhpark bluecodecom thestakeholdercompany decisiv michaeljguarino recruitee fozcodes calvinb gen1321 nerdyworm phil-a workpathco kanes115 ieatkimchi bzbzh kelcecil s-capybara eriosv gabrieltaylor patrickfung pepsico-ecommerce parker-bartlett semsee scriptdrop adanselm kim-company joeaxon-sauce serge2 rliebling aai pinksynth tsufurukawa jdl kokolegorille smartrent settld dropbox jakon89 isabella232 vladoplavsic disknee itsmonterey blockit richdom2185

samly's Issues

Extend config with cert and key and metadata

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,

Support for Cowboy 2.x?

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

Multiple NameIDFormat in IdP metadata

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?

InvalidCSRFTokenError

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?

Remove the need for supplying a certificate and keyfile if request not signed

If sign_requests and sign_metadata is set to false then there should be no need to supply a certificate or key.

Config to indicate if req/resp are signed

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

access_denied {:invalid_request, "{:error, {:invalid_response, \"%ErlangError{original: :data_error}\"}}"}

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.

SP metadata generated by samly is not considered valid with testshib.org

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.

sp.xml.zip

Generate a warning message when the IdP metadata file does not include SLO endpoint bindings

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.

Support for HTTP redirects when sending requests to IdP

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.

ADFS - AADSTS750056: SAML message was not properly base64-encoded.

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

Ability to customize state storage

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.

Argument Error

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

:badmatch error upon verifying response from ADFS

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

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.

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.

IdP initiated login

The ability for a login to start from an IdP portal

0.8.2 not matching SP metadata set in Shibboleth

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.

xml.zip

Include metadata filename in error message when there is an error

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.

Shibboleth demo sending empty assertion attributes

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

Working request/response/config for SimpleSAML: https://gist.github.com/hodak/a523c526d22ac96adfa7b21278b8cee0
Not working flow for Shibboleth: https://gist.github.com/hodak/6fb55b13798a5394ecde4eabb404e22a

Remove the built-in referrer check

Referrer checks are not specific to Samly. It is better to let a consuming application handle this.

Improve error reporting in dev mode

multi idp configuration issue

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

certs_and_idp_metadata.zip

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.

Keyfile is required even when Identity Provider Parameters are set to false

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.

add idp_id to Assertion prior to piping through pre_session_create_pipeline

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.

Does Samly manages users getting logged out if their permissions are revoked in their IDP?

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!

Dynamically adding identity providers

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.

"invalid_request unknown IdP" in production

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?

Handle namespaces in Identity Provider Metadata XML

OneLogin Samly How-to / Guide

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:

Samly.State.Store.get_assertion can actually get nil instead of assertion_key()

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.

use samly as IdP host

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

Okta SLO

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>

Digest verification failed on Idp

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?

"SLO Endpoint missing..." warning with GSuite

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

Exposing name_format to config

@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

Support for custom entityID attribute for SAML SP

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"

OneLogin IdP initiated Logout

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:

samly/lib/samly/sp_router.ex

Line 22 in 110d348

post "/logout/*idp_id_seg" do

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!

use with federation

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

<EntitiesDescriptor> tag support

Currently feeding Samly with metadata that describes federation (has <EntitiesDescriptor> tag in root) is not possible. Can we support that?

Shibboleth Single Logout - logout request fails

Check Issue: handnot2/esaml#1

Uptake this esaml fix.

Support for lists/multiple values in attributes

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

Configuration for multiple idps

With the current code, it's not possible to use more than one identity provider in your application.

Mismatched or missing 'RelayState' in IdP responses to SP initiated requests

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.

Mixed case in response headers

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.