Hi Won, >> We hit the gluu page but we get a 400 bad request error You are getting 400 from Gluu Server? Before getting Gluu Server login?

yes we get the gluu error page but we did not get a login page.

Ok.. I think i would check apache log in this case as 400 is coming from apache.

This is all I see in the /var/log/apache2/other_vhosts_access.log --------------- gluu.cloud.aws.qualcomm.com:443 10.64.96.87 - - [30/Jun/2017:17:04:12 +0000] "GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=fVLLTuMwFN3zFZH3tpNQldRqUlUDSJVAI7UwQrOpHOemeCaxg69NGb4eN21HsGF5rfPSOZ4v3vou%0AeQWH2pqSZCwlCRhlG212JXl8uKUFWVQXc5R9lw9iGfyzWcNLAPTJEhGcj7wf1mDowW3AvWoFj%2Bu7%0Akjx7P6Dg3NVOKtgD9ZESRZmMEiwg3ceb5kz28t1Gw53R3jJle97ZnTbcQaMdKE%2BS65Eo%2FRjwLLvr%0AQmCqs6Fhco%2FsJcgucvtRQDcDH5xtdQd8s7y%2Fy%2Fn6JMY3m58kWV2XZFtLmbVFXlDVtjWdTGdAZ5eQ%0A0qKe1pBN1CyVTYQiBlgZ9NL4kuRpdkXTKb1MH7IrkU5ElrE8T3%2BT5Ne5wPxQYKzUoDhWVpLgjLAS%0ANQoje0DhlTikEhEqYkxvle1IdWxYjIYuubWul%2F577uFFN7QdoQKM1%2F7fF%2B%2Fv6fK8HqkOsOMO4jSE%0AwEH832j7p27%2FPhU3q7c5%2F5yyOp1fv0X1AQ%3D%3D&RelayState=ZXlKMWMyVnlVRzl2YkVsa0lqb2lkWE10ZDJWemRDMHlYMnBpWm10WU9FVkplQ0lzSW5CeWIzWnBaR1Z5VG1GdFpTSTZJa2RzZFhVdFFWZFRJaXdpWTJ4cFpXNTBTV1FpT2lJMGJEaHFZbXhvTVdwd05XRXlPSE15TkhSdFl6azViVFkySWl3aWNtVmthWEpsWTNSVlVra2lPaUpvZEhSd2N6b3ZMek52WVRVNGVIRjNPV0V1WlhobFkzVjBaUzFoY0drdWRYTXRkMlZ6ZEMweUxtRnRZWHB2Ym1GM2N5NWpiMjB2WkdWMklpd2ljbVZ6Y0c5dWMyVlVlWEJsSWpvaWRHOXJaVzRpTENKd2NtOTJhV1JsY2xSNWNHVWlPaUpUUVUxTUlpd2ljMk52Y0dWeklqcGJJbUYzY3k1amIyZHVhWFJ2TG5OcFoyNXBiaTUxYzJWeUxtRmtiV2x1SWl3aVpXMWhhV3dpTENKdmNHVnVhV1FpTENKd2NtOW1hV3hsSWwwc0luTjBZWFJsSWpwdWRXeHNMQ0pqYjJSbFEyaGhiR3hsYm1kbElqcHVkV3hzTENKamIyUmxRMmhoYkd4bGJtZGxUV1YwYUc5a0lqcHVkV3hzZlE9PTp0L2ZndmlMOFY0L1pzNWdRMWxrMEg3L0Fvd3FPVWgyK0NzZjhDOUg4NG1vPQ%3D%3D HTTP/1.1" 400 1514 "https://rbracewe-testing.auth.us-west-2.amazoncognito.com/login?response_type=token&redirect_uri=https://3oa58xqw9a.execute-api.us-west-2.amazonaws.com/dev&client_id=4l8jblh1jp5a28s24tmc99m66" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0" --------------- Nothing else in the apache2 error.log

Ok, thanks. I think I need to give a shot by myself to check what's happening actually as I never tried this before. Any doc / link?

http://awsfeed.com/post/161338203754/amazon-cognito-user-pools-supports-federation-with http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-saml-idp.html

Thanks. Added in Todo list.

Hi, Won and Zico. Just've remembered I've seen something like this before. It's really quick tests, it whether will help to resolve it, or won't, then you'll should wait what Zico's investigation will show. This part of the request: ``` AssertionConsumerServiceURL="https://rbracewe-testing.auth.us-west-2.amazoncognito.com/login/redirect" ``` ...references endpoint at SP which IdP should use for response. Please make sure that assertion consumer endpoint in the SP's metadata has exactly the same url (case **does** matter) If it matches, then also please check whether this hostname - `rbracewe-testing.auth.us-west-2.amazoncognito.com` - is resolvable **from inside the container** (with `ping` or `dig`), and also that you can connect to port 443 of this host (with `ncat` or `telnet`) Hope this helps.

An example from TestShib SP's metadata: ``` <AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.testshib.org/Shibboleth.sso/SAML2/POST"></AssertionConsumerService> ``` Their request: ``` <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://sp.testshib.org/Shibboleth.sso/SAML2/POST" Destination="https://some.idp.host/idp/profile/SAML2/Redirect/SSO" ID="_18296bca76827f412f0c13f7a3a032b4" IssueInstant="2017-07-03T23:47:11Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.testshib.org/shibboleth-sp</saml:Issuer> <samlp:NameIDPolicy AllowCreate="1" /> </samlp:AuthnRequest> ``` You could also share metadata of your SP with us, would be easier to tell.

I could send you the metadata but could I send it to you in a private message? I also found out that currently AWS Cognito does not support the HTTP-POST binding for Authnrequest and only supports Redirect. Does Gluu not support the Redirect binding or did we not configure this correctly?

Oh and I forgot to mention that the URL rbracewe-testing.auth.us-west-2.amazoncognito.com is accessible from the AWS gluu service. I have tested telnet and I get a connection response.

One more related question. Most of the errors we see are happening when we hit the idp webapp. But when I look inside the idp webapp logs it shows nothing of interest. I don't see a way to set the logging levels of the idp to show debug information on the gluu console. Is there a way to increase the logging level on the IDP webapp? This may help us resolve what is failing in the interaction with Cognito.

SAML logging level is standard Shibboleth log; you can change/setup various level of SAML logging just like Shibboleth do; you just need to bounch 'idp' and 'identity' services after changing log level here in Gluu Server.

ok great thanks. I updated the logging levels to DEBUG and I am getting the following error in the shibboleth-idp logs. 2017-07-05 17:46:50,923 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.CheckMessageVersionHandler' on INBOUND message context 2017-07-05 17:46:50,923 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl' 2017-07-05 17:46:50,924 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.saml1.binding.impl.SAML1ArtifactRequestIssuerHandler' on INBOUND message context 2017-07-05 17:46:50,924 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl' 2017-07-05 17:46:50,924 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLProtocolAndRoleHandler' on INBOUND message context 2017-07-05 17:46:50,924 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl' 2017-07-05 17:46:50,925 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler' on INBOUND message context 2017-07-05 17:46:50,925 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl' 2017-07-05 17:46:50,926 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLAddAttributeConsumingServiceHandler' on INBOUND message context 2017-07-05 17:46:50,926 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl' 2017-07-05 17:46:50,926 - DEBUG [net.shibboleth.idp.saml.profile.impl.InitializeRelyingPartyContextFromSAMLPeer:132] - Profile Action InitializeRelyingPartyContextFromSAMLPeer: Attaching RelyingPartyContext based on SAML peer urn:amazon:cognito:sp:us-west-2_jbfkX8EIx 2017-07-05 17:46:50,927 - ERROR [net.shibboleth.idp.relyingparty.impl.ReloadingRelyingPartyConfigurationResolver:107] - RelyingPartyResolver 'shibboleth.RelyingPartyConfigurationResolver': error looking up Relying Party: Invalid configuration. 2017-07-05 17:46:50,927 - DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:131] - Profile Action SelectRelyingPartyConfiguration: No relying party configuration applies to this request 2017-07-05 17:46:50,928 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: InvalidRelyingPartyConfiguration

ok the good news is that I deleted my gluu service and reinstalled it and now the SSO redirect seems to be working but we are now getting an error on the AWS Cognito side. Not sure why it was failing before but starting from scratch and cleaning up the previous trust relationships seems to have cleared up the authentication flow. So I have reached out to our AWS support to try to get more logging information from Cognito which seems to not like the token that is being passed back from the SAML Response from Gluu.

OK, let us know what you hear.

So the issue that AWS Cognito was getting is that the generated transient ID in the NameID within the Saml Response was too long. Is there a way to shorten the transient ID? AWS said that they have a character limit and said they will see if they can remove that limit, so for now I switched the nameID to using the persistent ID using mail as the seed for the ID hash. This shortened the NameID value and seems to be accepting the SamlResponse from Gluu into Cognito. I have successfully been able to get a an O-Auth code token from Cognito and convert them to id_token and access_token via Cognito's O-Auth API. Once I can get that I am seeing if I could trade these tokens for AWS access/secret/session keys to make service calls within AWS Lambda functions into other AWS services.

Hi Won, Just touching base to know... are you waiting on us for something? I mean... should we keep this ticket open?

So sorry I did not respond back sooner. So here the run down of what we were able to accomplish. We were able to get gluu working as an IDP with AWS Cognito, API Gateway and Lambda function. The major issues we ran into with Gluu was getting the nameID switched to a shorter value such as persistentId. After that we were able to pass the SamlResponse back to Cognito, get a id_token from Cognito and verify the tokens in API gateway authorizer and finally call a lambda function. We may look at this POC for future single page web apps or native apps to leverage Lambda functions in AWS as a data source. thanks for your help. You can close this ticket at this point.

No problem at all, Won. Thanks much.

I'm trying to implement the Gluu with AWS Cognito login as well to do the same thing as Won Kim as doing in order to obtain the IAM credentials. Won Kim, could you happen to explain what you did to shorten the value of the NameID? I continue to get "<domain>?error_description=Error+in+SAML+response+processing%3A+Internal+server+error.+&error=server_error" upon the redirect back to my application after the SAML post back to the Cognito User Pool. I have created a SPSSODescriptor file for the cognito pool similar to what was available via the AWS IAM definition. I have tried NameIDFormat as such: <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat> If I don't put in the :transient than I don't get a NameID in the assertion. and looking in the saml-nameid.xml.vm file it appears that 3.1.3 should only be using the mail property for the transient resolver. <!-- SAML 1 NameIdentifier Generation --> <util:list id="shibboleth.SAML1NameIdentifierGenerators"> <ref bean="shibboleth.SAML1TransientGenerator" /> <!-- <bean parent="shibboleth.SAML1AttributeSourcedGenerator" p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" p:attributeSourceIds="#{ {'mail'} }" /> --> </util:list> Any help would be appreciated.

Hi Jason, I think it's better if you can open a new issue, current ticket is pretty old to track. :-)

sorry for the late reply but this was something I worked on a while ago and I had to re-dig up my notes. I wasn't able to shorten the transient-id shortened we just switched to using persistent-id which was already a shorter value so that worked with Cognito. Hope this helps. Won

Thanks for the reply Won, I am having issues trying to get anything but the transientId created so I will do as Mohib suggested and open a new ticket to try and trace this down since I'm sure a lot has change in the config with newer versions over time. Thanks again.