Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Warning

This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.

...

The SAML-related documentation is mostly under https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation.html but testing this really requires a bit of work with their OAuth support to at least mock up test cases.

Note that unlike AWS-proper, each Cognito User Pool is its own SP and is handled distinctly.

Table of Contents

Identity Provider Metadata

...

They do not provide any SP metadata; it has to be manually pieced together from their documentation and that's somewhat scattered across different pages and you have know to know what you're looking for.

...

Code Block
languagexml
titleExample relying-party.xml override
collapsetrue
	<!-- Container for any overrides you want to add. -->

	<util:list id="shibboleth.RelyingPartyOverrides">

		<!-- other overrides... -->

		<bean p:id="example.SignAssertionsOnlyDisableEncryption" parent="RelyingPartyByName">
			<constructor-arg name="relyingPartyIds">
				<list>
					<value>urn:amazon:cognito:sp:us-east-2_poolid</value>
				</list>
			</constructor-arg>
			<property name="profileConfigurations">
				<list>
					<bean parent="SAML2.SSO" p:encryptAssertions="truefalse" />
					<bean parent="SAML2.Logout" />
				</list>
			</property>
		</bean>

	</util:list>

...

As with most vendor documentation, they are inaccurate regarding this piece. They do require a NameID and it's the basis of an auto-generated username value in the user pool. It does not have to be any particular Format, and they mis-speak by suggesting you should use "persistent". You certainly can, but you would need to understand that they'll be visible in the pool and of course it means correlation between pools would not be easy to dopossible. That may be good or bad, it just depends on your needs. If you want to use a more globally consistent value, you can, just pick a different Format.

Whatever you use, it will construct the eventual username key based on combining the IdP "name" with the NameID value with an underscore in between them. So it essentially auto-scopes the value with a prefix.

Having settled on a Format, make sure you add that to the Cognito metadata in a <md:NameIDFormat> element to trigger its use.

Attribute Requirements

Cognito essentially acts like a simplistic kind of user directory, and it supports a number of pre-defined attributes and allows custom fields to be created. A subset of them can be marked as "required" when the pool is created, but not changed afterward.

...