I'm doing a proof of concept for federating SAML into Cognito. I've setup Shibboleth v3, and once I finally got the log level set, I can see the SAML being sent back to Cognito, which just redirects to my configured page with ?error_description=Error+in+SAML+response+processing%3A+Invalid+SAML+metadata.+&error=server_error in the URL. The user pool in Cognito is set to require an email address, and I think I've got the attribute mapping set correctly, but it's not really easy to tell. Here's the SAML I'm seeing in the logs (minus a couple of URLs for anonymization's sake):
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response
Destination="https://{DOMAIN}.auth.us-east-1.amazoncognito.com/saml2/idpresponse"
ID="_cc28aebe7ae433f549a7df77e8a2fbaa"
InResponseTo="_d34b0821-c6eb-408d-b687-5fb2b71422dd"
IssueInstant="2019-06-10T18:00:23.314Z" Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp1.example.com:8443/idp/shibboleth
</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="#_cc28aebe7ae433f549a7df77e8a2fbaa">
<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#">
<ec:InclusiveNamespaces PrefixList="xsd" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>3wL9vw0MsEuSGO+0bir/6GQV1FVNQHw4fLgAXteHQK0=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
LvCSLdm87hWsK480jhv/8JXBciPmGmAeUVxkGpAKUal5omnmpASXflSBHutkRwyPzD6mXMgSk3xL
f0IfWwspbA3ixmbbeEwQciel+2Y4WxwPpWreV1aLHMLYSj8x8ZdiDSioczMwRpQSqVo6RCX98ayo
riTBwTaoIQTHcE6xdDb98zDVCL+tCvrgkT3fhl0Z9HBxDvdy/YyrEuv0QVTj9SHiTI6heY5AhvA8
3qCAaGdbsNc0jqvy6AUAp1VBy8QJGpWMvChXJnO8srUEKkVBhGRfScCaO2uDcpa90zAlSuD1B7Q7
vVVrahRCB2lJHEmAyM2XeNNwN+DbyFU2Lcz4Kg==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDVDCCAjygAwIBAgIUIBWSFzIstjdAx2yVXLC40xKOIYAwDQYJKoZIhvcNAQELBQAwJzElMCMG
A1UEAwwcaXAtMTAtMjAzLTEwLTkxLmVjMi5pbnRlcm5hbDAeFw0xOTA2MDQyMTU1MDhaFw0zOTA2
MDQyMTU1MDhaMCcxJTAjBgNVBAMMHGlwLTEwLTIwMy0xMC05MS5lYzIuaW50ZXJuYWwwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCaaLJ5lqB8eWuIiKPhDVsxOBncTnVS7wjjQOJ6pkSJ
El8G1MnMIb5xaQBv9luwq88+EcmWIZDzt4Yj326tmz4lwweWa4VI3iVfk6eZl7Zpwlcj57dtvA8B
MhcmbqX56Kb3pmTLf4VAI8hPoHdmKNYFapy+uM4b6ubvLx1NxlzgWfZ3o0ZrTuOpNpFgXJB+FGMS
au4lOCvOVchU7ymch2qwP/iFSUnNcviL9k/M4tSIkbf+Tb9o9SQrJhwcBMdQDfsLKnDhEtvovX12
H70smzVCg/H3AVUE+Qne5Cget90xKKRtQcSV2Q4jIS0mRGc5XVEQEiVzOLvx6DyLXUs926JxAgMB
AAGjeDB2MB0GA1UdDgQWBBT0+FXPDXOe+gtZsNA+dnzPvJysWzBVBgNVHREETjBMghxpcC0xMC0y
MDMtMTAtOTEuZWMyLmludGVybmFshixodHRwczovL2lkcDEuZXhhbXBsZS5jb206ODQ0My9pZHAv
c2hpYmJvbGV0aDANBgkqhkiG9w0BAQsFAAOCAQEAaM1kS0CoKBy4l1wRihbvsfX78FCmKk4woWEk
a0st/c42ntf7nU8b/4C6SV9Jl7rhij18um6tF6dv+pVsH5KrDQbdH3xwF24ekDqosEaHSxcmY79k
1TePd00xH8/udeKRFc+78LnkygnzulZZ748XKj9/ehUkfbrhWhGP3333Nruj5Ptlv7d4upCxtQ+g
dYmHIzFt26MHR5jxcwYWPd/4M1ElakevscWOBjKTpScOnMYOikzyZpS+p7hD5/z4OfKv6AWLPdek
eWVXGlZhRKhtp15tRrUpQucZFMh+YNOm9IlBRBeh5Qw4KQgg1KvkNy1+iA9vfptn+f2CtPhF+cxx
3Q==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
<saml2:Assertion ID="_4df74e3ced3d853e5a0c329e0f7c83cb"
IssueInstant="2019-06-10T18:00:23.314Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>https://idp1.example.com:8443/idp/shibboleth</saml2:Issuer>
<saml2:Subject>
<saml2:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://idp1.example.com:8443/idp/shibboleth" SPNameQualifier="urn:amazon:cognito:sp:us-east-1_MyLIE83bf">AAdzZWNyZXQxrczu0aLzz4zQafYgy5VN8rTutrL827I6iPTAGPVAGJlJKAcQIHAdkWP1uqtsYqAccnsy0GPpTNx8GgTudWw6Q5ovEh/zSlYq+A/eExrAuT5sJlatEGua7boJDq63t1fESo4qOmz3uW+Pbik=
</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="10.203.10.25"
InResponseTo="_d34b0821-c6eb-408d-b687-5fb2b71422dd"
NotOnOrAfter="2019-06-10T18:05:23.730Z" Recipient="https://{DOMAIN}.auth.us-east-1.amazoncognito.com/saml2/idpresponse"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2019-06-10T18:00:23.314Z" NotOnOrAfter="2019-06-10T18:05:23.314Z">
<saml2:AudienceRestriction>
<saml2:Audience>urn:amazon:cognito:sp:us-east-1_MyLIE83bf</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2019-06-10T18:00:12.508Z" SessionIndex="_c1e143fa5c01b3642d1ce4573bfe9465">
<saml2:SubjectLocality Address="10.203.10.25"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue>bob#example.com</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="Role" Name="https://aws.amazon.com/SAML/Attributes/Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">arn:aws:iam::{ACCOUNT}:role/FederationWorkshop-ReadOnly,arn:aws:iam::{ACCOUNT}:saml-provider/idp1 </saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="RoleSessionName" Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">bob</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
Is there something simple I'm missing (the intricacies of SAML and SSO are definitely not my wheelhouse at this point in time).
Question: "Why is Cognito rejecting my SAML assertion?"
Quick Response:
Three potential root causes of this issue:
(1) Your SAML assertion does NOT carry/deliver all the attributes required by Cognito (see the detailed answer and resolution below).
(2) Attributes do NOT meet the format required by Cognito.
For example, (Note that please replace "ACCOUNT_NUMBER" with your aws id assigned by Amazon AWS (e.g., 123456789012))
attribute #1: awsRoles
attribute #1 value: arn:aws:iam::ACCOUNT_NUMBER:role/shibbolethidp,arn:aws:iam::ACCOUNT_NUMBER:saml-provider/Shibboleth-IdP
attribute #2: awsRoleSessionName
attribute #2 value: winston.hong#example.com
(3) Attribute values do NOT registered at Cognito through ADMIN console of Amazon AWS (see (II) Important Remarks on Role later on).
Remarks
(1) Adding SAML Identity Providers to a User Pool states that Audience URI/SP Entity ID of User Pool (NOT Identity Pool) is urn:amazon:cognito:sp:your-User-Pool-ID.
(2) How to enable secure access to Kibana using AWS Single Sign-On describes how to utilize AWS SSO to access Kibana (Amazon Elasticsearch Service, an AWS internal service).
An example of two important SAML SP parameters for User Pool (NOT Identity Pool) is provided below.
(I) Application ACS URL: https://<Elasticsearch domain name>.auth.<AWS region>.amazoncognito.com/saml2/idpresponse
(II) Application SAML audience: urn:amazon:cognito:sp:<user pool id>
Question: "The user pool in Cognito is set to require an email address, and I think I've got the attribute mapping set correctly, but it's not really easy to tell."
Answer:
Your SAML response indicates that your attribute mapping is NOT set correctly.
(1) Attribute "RoleSessionName" carried by your Shibboleth IdP v3 SAML response to Cognito is NOT required by Cognito.
<saml2:Attribute FriendlyName="RoleSessionName" Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">bob</saml2:AttributeValue>
</saml2:Attribute>
The correct attribute "RoleSessionName" carried by Shibboleth IdP v3 SAML response to Cognito should be your E-mail address "bob#example.com" instead of your given name "bob".
<saml2:Attribute FriendlyName="RoleSessionName" Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">bob#example.com</saml2:AttributeValue> </saml2:Attribute>
(2) Resolution:(minor revision may be required depending on your data repository such as LDAP)
Add attribute resolution
<resolver:AttributeDefinition id="awsRoles" xsi:type="ad:Simple" sourceAttributeID="employeeType">
<resolver:Dependency ref="myLDAP"/>
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="https://aws.amazon.com/SAML/Attributes/Role"
friendlyName="Role" />
</resolver:AttributeDefinition>
<resolver:AttributeDefinition id="awsRoleSessionName" xsi:type="ad:Simple" sourceAttributeID="mail">
<resolver:Dependency ref="myLDAP"/>
<resolver:AttributeEncoder xsi:type="enc:SAML2String" name="https://aws.amazon.com/SAML/Attributes/RoleSessionName"
friendlyName="RoleSessionName" />
</resolver:AttributeDefinition>
into "attribute-resolver-full.xml" or "attribute-resolver.xml" (depending on your Shibboleth IdP configuration). Shibboleth IdP Attribute Resolver Example.
Note that OpenLDAP attribute "employeeType" is used to carry the role of Amazon AWS. Your data store/repository may use different attribute to carry the role of Amazon AWS.
(I) The following OpenLDAP attributes have been mapped with AWS configuration through AWS administration console.
mail: winston.hong#example.com
employeeType: arn:aws:iam::ACCOUNT_NUMBER:role/shibbolethidp,arn:aws:iam::ACCOUNT_NUMBER:saml-provider/Shibboleth-IdP
(II) We provide the official link of configuring Amazon AWS with Google G Suite to describe SAML IdP configuration steps (performed through AWS administration console):
Cognito Configuring Your Identity Pool for a SAML Provider states that
Before configuring your identity pool to support a SAML provider, you must first configure the SAML identity provider in the IAM console. For more information, see Integrating third-party SAML solution providers with AWS in the IAM User Guide.
Integrating third-party SAML solution providers with AWS states that
Amazon Web Services cloud application – This article on the Google G Suite Administrator Help site describes how to configure G Suite as a SAML 2.0 IdP with AWS as the service provider.
Access the link of Google G Suite Amazon Web Services cloud application, and then Click "Step 1: Set up Amazon Web Services as a SAML 2.0 service provider (SP)", you can get the following SAML configuration steps of Amazon AWS for Cognito.
4. log in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
5. In the navigation pane, select identity providers and then click Create SAML Provider.
6. Select SAML as the Provider Type, and give it a name such as GoogleApps.
7. Upload the IDP metadata you saved earlier from the Google Admin console SAML settings.
8. Click Next Step and on the following page, click Create.
9. Click the Roles tab on the left sidebar and click Create a New Role to create a role which will define the permissions.
10. Select Set role name. This name will be displayed next to the login name on the AWS console.
11. Select Role for Identity Provider Access.
12. Select Grant Web Single Sign-On (WebSSO) access to SAML providers. Click Next Step.
13. Leave the Establish trust settings as they are. Click Next Step.
14. Use the Attach policy settings to define the policies your Federated Users will have. Click Next Step.
15. On the following page, review your settings, then click Create the Role.
16. Select your Google service from the identity providers list and note the Provider ARN. This contains your AWS Account ID and the name of the provider (example: arn:aws:iam::ACCOUNT_NUMBER:saml-provider/GoogleApps).
17. Click Save to save the Federated Web single sign-on configuration details.
Important Remarks on Role
(a) OpenLDAP attribute "employeeType" is Role in my validation experiment with AWS console.
(b) Ensure that OpenLDAP attribute "employeeType" is mapped with your AWS configuration setting "Role"**
(c) Replace "GoogleApps" with "Shibboleth-IdP" for Provider Type
(d) Set role name (e.g., shibbolethidp or googleapps, which will be converted by AWS into arn:aws:iam::ACCOUNT_NUMBER:role/shibbolethidp or arn:aws:iam::ACCOUNT_NUMBER:role/googleapps)
(III) For your convenience, I have made the 9th commit to upload the Amazon AWS SP metadata and corresponding SAML configuration to How to build and run Shibboleth SAML IdP and SP using Docker container.
Note that I have logged in to Amazon AWS account ("ACCOUNT_NUMBER", e.g., 123456789012) with username "winston.hong#example.com" successfully using Shibboleth IdP running with Docker Container with the 9th commit.
By performing the Shibboleth SAML IdP configuration with reference to the 9th commit to How to build and run Shibboleth SAML IdP and SP using Docker container, you can log in to your Amazon AWS account ("ACCOUNT_NUMBER", e.g., 123456789012) with your username (such as "winston.hong#your-company.com") federated by Shibboleth IdP..
(IV) My SAML response for successful login to AWS is provided below for your reference.
<saml2p:Response Destination="https://signin.aws.amazon.com/saml"
ID="_fc89710799c4c2c540341e94bf7132d5"
IssueInstant="2019-06-11T18:49:38.300Z"
Version="2.0"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com/idp/shibboleth</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</saml2p:Status>
<saml2:Assertion ID="_91749d5ecb8512c0c5d658a77cb25928"
IssueInstant="2019-06-11T18:49:38.300Z"
Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>
<saml2:Issuer>https://idp.example.com/idp/shibboleth</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="#_91749d5ecb8512c0c5d658a77cb25928">
<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#">
<ec:InclusiveNamespaces PrefixList="xsd"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>mDAgwb9ZJxc+01sC99lAlAIAOEoiTgzHVTm4F9bdn/0=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
LWiL3+CdU6y86zBLx3vG6na1o46EUgiN7iV+b4J2lPvZK7+Oeu6XSenJlzo/cUMT19pYYrDMM652
3lDAJCuOKPx4zTRIcabGrgzTKgmen0SHqWPxeL7t23RB6+v5AUvVw02tXqQhlggKEe3H+1T1k5q0
cGc1xw5CQtI8zE6GK7nG1INnU7mo872H9x+zM1zy3yyvrWOkHHhVFqQQ1Tu+0ev4BIhTQaVgC+pM
/ZvpctNjDMl1q4RSt1qumC+KFsYZlbrsLG7AvGJuR39wt/HV7F8Je3AUGGwMtGjkpRDuN1lIHrMq
VzFf/5eKUv20rEk3aOxoV/sMfcuhWo27+NjE1g==
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIDPDCCAiSgAwIBAgIVALPPoC598LJ6ZJJJXCA2ESASlN4AMA0GCSqGSIb3DQEBCwUAMB8xHTAb
BgNVBAMMFGlkcXNhbWwuaWRxdWFudGEuY29tMB4XDTE3MDYwMjIxNDI0NloXDTM3MDYwMjIxNDI0
NlowHzEdMBsGA1UEAwwUaWRxc2FtbC5pZHF1YW50YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAs4ml4G592b059YDgyD/MLWQKaKrc0/24Ufbl/JY7wOI1RpxW8DlbCvibzQge6Tu
/8LVy4GIDb8QLxmCfFKYn97HC68TgXVJ+m+sQm+e4SVg6V2q+JY94LLcoFVe8+78ZIYT23KLkTv2
RlHzes/sL1YaPSK4UuN+/ezppyX2t9BGNfuiUKA0KCf7wMFuQ07Fr65FTcGXQyxhPyaNrXjrNMJa
LqwpCaesVdVzoqPevYVN3+nzAvOWoEbi6IcwnF07D0FYren/GPRXPAk5sP6fF3X0rJCkSq+d5t5P
0gWONlvm9WlUrKadmeiibCtR2lGQ/dZGmyUzIILsuOwu4yp/EsI3AgMBAAGjbzBtMB0GA1UdDgQW
BBREpZrZlnm8YrbSFcl59WRR5IY2FTBMBgNVHREERTBDghRpZHFzYW1sLmlkcXVhbnRhLmNvbYYr
aHR0cHM6Ly9pZHFzYWQCV63ubc+tsfzCvL48k35RzLAD15DIdbS9pZHAvc2hpYmJvbGV0aDANBgk
AAOCAQEAEvrdnSvK2C2rcRr7kXn4Q/NaEovuUeqaNs1k/2+dSqs8rroM+m3Iq8RlBcmKnP/+mET3
wwUaWRxc2FtbC5pZHF1YW50YS5jb20wggEiLRXay9y1uJXyZx37RDkGu8SD7+zf8znM+TCsX/qAP
6Ve95WAeX4uB8Aeol3LULe1dePsRb/1RNpKsm8NomVzCwBXK9vyv8t3IVN40jZMaaTtR0YR22fTu
qTyIMarMPO0Eh0f1FHraYaXfyop1OJcYlISpYe+c4vNvAXwEtHkZD2Iu/2aEMGcvBo3uq6OYVDXO
fI3CvoB7sRtxURtj+vVSZKjDe6s7+lRcE1tpDkwOEEuDzA==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://idp.example.com/idp/shibboleth"
SPNameQualifier="urn:amazon:webservices"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>AAdzZWNyZXQx/wu+MEcVaUwjGOXhDKAO/5KXLD2AcDGnu1DyoP2C4ztOF01Su6tTJDytykrsv7W2dSV4FkL42ORYDiipBEuwiRSbnvViKbFBkHYN4YUmQzttx3DPNW/w42tMjLrY2iyn7sAUgQSVNGRHyMAH</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="192.168.150.10"
NotOnOrAfter="2019-06-11T18:54:38.412Z"
Recipient="https://signin.aws.amazon.com/saml"
/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2019-06-11T18:49:38.300Z"
NotOnOrAfter="2019-06-11T18:54:38.300Z"
>
<saml2:AudienceRestriction>
<saml2:Audience>urn:amazon:webservices</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2019-06-11T18:49:38.041Z"
SessionIndex="_79ee919a4e3fcd2f6d13702b60bfd357"
>
<saml2:SubjectLocality Address="192.168.150.10" />
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="Role"
Name="https://aws.amazon.com/SAML/Attributes/Role"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string"
>arn:aws:iam::my-aws-id:role/shibbolethidp,arn:aws:iam::my-aws-id:saml-provider/Shibboleth-IdP</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="RoleSessionName"
Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string"
>winston.hong#example.com</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
</saml2p:Response>
(3) Amazon AWS provides the configuration guide How to Use Shibboleth for Single Sign-On to the AWS Management Console.
Shibboleth provides the configuration guide Shibboleth IdP with Amazon Cognito
(4) How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
(I) I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
(II) I have validated Shibboleth IdP with Amazon AWS Management Console with reference to How to Use Shibboleth for Single Sign-On to the AWS Management Console
(III) We developed our former version of Zero-Password Authentication and Authorization System in Java and leveraged Shibboleth IdP to provide SAML SSO for enterprise applications.
We developed our current version of Zero-Password Authentication and Authorization System with scalability and high availability in Scala to provide SAML SSO natively for enterprise applications without Shibboleth IdP.
Another StackOverflow question "Setting up a new Shibboleth IdP to work with an existing SAML SP" provides valuable information and discussions on Shibboleth SAML configuration.
I used PHP, LightSaml for my SSO SP Initiated
I had my service which I wanted to be an IdP and outside service which were a SP.
After I wrote my own script for receiving SAMLRequest, sending SAMLResponse and sent XML Metadata to the SP owner (he configured Cognito by this)
I had the same error in the browser console
error_description:Error in SAML response processing: Invalid SAML metadata.
So there are few steps which caught my attention while fighting with this error:
Check if all data in XML Metadata are correct
Check if your SAMLResponse include relayState and "InResponseTo" parameter in < samlp:Response > (which is ID of SAMLRequest)
Check if nameID format is correct and it is the same as server needs
Check if EntityId is correct in all places
Check attribute mapping in Cognito
Related
I have an application (Archibus) that can be configured to use SAML for application level authentication and uses OIDC for the REST apis w/in the application.
The problem Im having is that when I enable SAML authentication for the application, the REST API calls are getting stopped by the same SAML login, vs. bypassing SAML and using the JWT token I've already created via OIDC.
Im trying to figure out how to configure Shibboleth to allow a URL to bypass the SAML auth
https://my.site.com/archibus/api/v1/data/?dataSource=Api_Buildings <-- just use the JWT Token
https://my.site.com/archibus <-- use SAML for auth
I configured a RequestMap Path to not requireSession for the archbus/api path and then to requireSession for the rest of application path. When I put the api path first, postman works and returns data, but the application doesnt launch and I cannot login via SAML;
If i put the application first and /api 2nd, the application launches, but the API doesnt work:
<Host name="my.site.com" scheme="https" port="443">
<Path name="archibus/api/v1/data"/>
<Path name="secure" authType="shibboleth" requireSession="true"/>
<Path name="archibus" authType="shibboleth" requireSession="true">
<!--Path name="api" requireSession="false">
<Path name="v1" requireSession="false">
<Path name="data" requireSession="false"/>
</Path>
</Path-->
</Path>
</Host>
We have an application running on Tomcat currently and using LDAP as the means to authenticate users to our enterprise AD.
It is required to migrate this application to cloud (on AWS EC2) and to integrate with ADFS over SAML for login with MFA enabled.
Wondering if there are any guides on the the steps to be followed to make this happen ? What are the configurations that I need to enable in ADFS for my application and what configuration changes are needed on tomcat server.xml to have the connector integrate with ADFS rather than LDAP. Thanks.
Regards,
Raunak
Not a Tomcat guru but from the point of view of ADFS and SAML:
You need to use a client-side SAML stack in your application. This provides the SAML plumbing.
You then need to add a SAML RP to ADFS.
For MFA, typically you use Azure AD to provide the MFA.
(There used to be an on-premises ADFS MFA Server - that is now deprecated).
If that is not an option, there are third-party providers.
I am trying to integrate a Google Identity Platform SAML provider with Okta. Typically the flow that have used to use a GIP provider, is this process where you provide the provider ID, and wait for the callback. This works correctly with Okta as an identity. However, in order to create the Okta integration, (and allow the user to click the application and be taken to the website) you need to provide the ACS(assertion consumer service), which in this case would be https://my-app-12345.firebaseapp.com/__/auth/handler however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?
Question:
I am trying to integrate a Google Identity Platform SAML provider with Okta. Typically the flow that have used to use a GIP provider, is this process where you provide the provider ID, and wait for the callback. This works correctly with Okta as an identity.
Answer:
(1) Okta supports the third party SAML identity provider such as Google Identity Platform or Shibboleth IdP.
(I) Google Identity Platform is SAML identity provider. Okta is SAML service provider.
(II) Okta is SAML identity provider. Web application (such as Office 365, Salesforce, Dropbox, Box, etc.) is SAML service provider.
(2) A user can log in to a web application via Okta by using the credential of the third party SAML identity provider of Okta.
I have validated the following user identity federation procedure for Salesforce (a web application) from the web application perspective:
(I) A user accesses their Salesforce organization domain (such as https://example.my.salesforce.com/)
(II) Select Log In with a Different Provider > Okta with Google Identity Platform
(III) The user is redirected to Google Identity Platform via Okta
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back by Google Identity Platform and Okta, and then is logged in to their Salesforce account successfully.
Note that the user's username for Google Identity Platform, Okta account and Salesforce account is the same, i.e., winston.hong#example.com for their organization example.com
Question:
However, in order to create the Okta integration, (and allow the user to click the application and be taken to the website) you need to provide the ACS(assertion consumer service), which in this case would be https://my-app-12345.firebaseapp.com/__/auth/handler however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?
Answer:
(1) As a SAML identity provider, Okta supports both SAML SP-Initiated flow and SAML IdP-Initiated flow.
As a SAML service provider, Salesforce supports SAML SP-Initiated flow.
(2) In order to create the Okta integration and allow the user to click the application and be taken to the website (such as Salesforce organization domain https://example.my.salesforce.com/), you do NOT need to provide the ACS (assertion consumer service) URL, Instead, you need to provide the organization domain of Salesforce, i.e.,
Application label Salesforce.com
Instance Type Production
Custom Domain example
(3) A user can log in to a web application via Okta by using the credential of the third party SAML identity provider of Okta.
I have validated the following user identity federation procedure for Salesforce (a web application) from the Okta perspective (This is your use case):
(I) A user accesses their Okta organization domain (such as https://example.okta.com/)
(II) Click Need help signing in? and then click Log in with Google
(III) The user is redirected to Google Identity Platform
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back and then is logged in to their Okta account successfully
(VI) On their Okta home screen, the user click Salesforce application icon
(VII) The user is redirected to their Salesforce organization domain, and then is logged in to their Salesforce account successfully.
Issue:
Quote "however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?"
Resolution:
(1) This is exactly SAML SP ACS issue of your web application https://my-app-12345.firebaseapp.com/__/auth/handler.
(2) You have to either modify the SAML SP configuration of your web application or modify the SAML SP source code of your web application, because the SAML SP ACS endpoint of your web application does NOT redirect to your web application page after verifying SAML signature sent by Okta SAML IdP.
(3) I have validated the following user identity federation procedure for Shibboleth SAML SP demo application (a web application parallel to your web application) from the Okta perspective (This is your use case):
(I) A user accesses their Okta organization domain (such as https://example.okta.com/)
(II) Click Need help signing in? and then click Log in with Google
(III) The user is redirected to Google Identity Platform
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back and then is logged in to their Okta account successfully
(VI) On their Okta home screen, the user click Shibboleth SAML SP demo application icon
(VII) The user is redirected to Shibboleth SAML SP demo application, and then is logged in to their Shibboleth SAML SP demo application successfully.
(4) The configuration of a general SAML SP application through Okta Admin GUI
Shibboleth SAML SP demo application (parallel to your web application my-app-12345.firebaseapp.com)
Applications > Shibboleth SAML SP demo > SAML Settings
Single Sign On URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Recipient URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Destination URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Audience Restriction https://samlsp.example.com/Shibboleth.sso/Metadata
Note that Single Sign On URL is ACS URL of SAML SP of your web application.
(5) How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building your own IDP for SAML in Java using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
(I) I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
(II) I have also leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to Salesforce and Shibboleth SAML SP demo application via Okta successfully.
Shibboleth SAML IdP is SAML identity provider (parallel to Google Identity Platform), Okta is SAML service provider.
Okta is SAML identity provider. Web application (such as Salesforce and Shibboleth SAML SP application) is SAML service provider.
(III) For your convenience, I have made the 11th commit to upload the Okta SP metadata and corresponding SAML configuration to How to build and run Shibboleth SAML IdP and SP using Docker container.
Note that I have logged in to Salesforce organization "example.com" account (https://example.my.salesforce.com) with username "winston.hong#example.com" successfully via Okta by using Shibboleth IdP running with Docker Container.
(IV) How to build and run Shibboleth SAML IdP and SP using Docker container provides the SAML SP configuration for SAML SP demo application.
For a 1 day project (call it a hackathon) we will be looking into replacing a custom built authentication and authorization system with one that we can buy.
After all, there are people who are better at this stuff than we are.
Non-cloud, hard requirement is on-premise installation possible
Can authenticate against Active Directory using LDAP
Can authenticate using SAML against ADFS
Management of users, roles etc without a directory is an option (most likely option to actually use during the hackathon)
Use open standards, SAML, OpenID, OAuth2
There are so many SAML-based products, but many are cloud-only, which unfortunately for us is not an option (reason: our products run on closed enterprise networks), so services like Okta are unfortunately not an option :(
The following list is quite complete, but doesn't give me any indication on how hard it is to install + get up and running in a few hours:
https://en.wikipedia.org/wiki/SAML-based_products_and_services
Any suggestions for products to try?
My eye caught these ones:
miniOrange, Ping Identity, 10duke
[addition]
I am using a Java stack for web apps.
How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building a SAML-based Authentication/Authorization Provider using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
Another StackOverflow question Setting up a new Shibboleth IdP to work with an existing SAML SP discusses the SAML configuration between IdP and SP.
OpenLDAP is not OpenID Connect or OAuth 2.0
Have a look at identityserver4.
It's OpenID Connect / OAuth2 by design and it does have a plug-in SAML stack.
Or if you have a Windows server, use ADFS.
FOSS - Shibboleth or KeyCloak
The definition of 'closed' (network) might be interesting to examine. No access to outside at all, not on any port, noway/nohow? In that case, yes, you want an on-prem service. If there's gated access to outside, it's likely that many hosted identity services could work.
Please note I am new to the applications I am mentioning so I might use the terminology incorrectly. I've added a few diagrams to explain myself as best I could.
I am trying to setup a web service authentication policy in APIMAN (which uses Keycloak internally)
So far I know the Identity Provider (OpenAM) I created in Keycloak is configured correctly since it is working on the Login page (see image 1 below)
I have also successfully used an access_token via Keycloak's OpenID API to access a web service; but only if the user credentials are in Keycloak (as oppossed to OpenAM) (see image 2)
What I'd like to achieve is to authenticate this web service client via Keycloak but using the Identity Provider's credentials, but I do not know how to do this or if it is even possible. (see image 3)
Please note I also tried User Federation with the LDAP behind OpenAM and it worked correctly, but I would like to know if there is a way to do it via OpenAM.
The way you used keycloak and openam is quite unusual, however if i understand correctlly your question, you want keycloak to redirect the webservice request to openam, not ldap,
You can either:
configure openam as a identity provider using saml:
Openam would be your source of identity, and keyclaok would be his clients, you can do this by configuring keycloak: identity provider -> saml IDP -> and here you will place openam metadata.
configure openam as OIDC provider:
In keycloak you go to identity providers -> create -> oidc v1 provider -> and you will place your openam info.
As i said, its can be done, but its not the way its suppossed to be, openam and keycloak are both Access management software, they both do exactly the same thing, in your configuration keycloak play a role of an API gateway, which is not exactly what keycloak should be doing, you can get get rid of either one of the solutions, both can provide you the same functionnalities (OIDC, OAuth2, SAML, LDAP, ...)