We have a custom PHP app, and from within that there is a link that allows users to get to our tableau server. We use SSO with SAML for authentications. When a user logs into the PHP app they are authenticated with our IdP, auth0. Then when they want to go to the tableau server that sends a SAML request to auth0.
We are having 2 issues:
1) If you go directly to the tableau server (i.e. from a browser, not from the PHP app) it sends a auth request to auth0 for the Tabadmin user. If tabadmin had previously authorized with auth0 and their session has not timed out they are granted access. How can I control what username is used by tableau when none is specified?
2) When tableau gets an access request from the PHP app it checks to see if there already is a cookie and if so, logs the user in as that cookie's user (without going to auth0) even if the request is from a different user. Is there a way to fix or control that?
Related
When trying to login via my AWS Cognito's login page via Azure AD with email#live.com credentials, I'm being redirected to https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=51483342-xxx-xxx-xxx-xxxx... and the page is throwing a 404 error.
Steps:
Created an Azure AD Enterprise Non Gallery Application.
Added identifier to enterprise application: urn:amazon:cognito:sp:ap-southeast-1_xxxxx
Added reply url as: https://xxxxx.auth.ap-southeast-1.amazoncognito.com/saml2/idpresponse
Downloaded the SAML Signing Certificate > Federation Metadata XML and uploaded it on Cognito by adding a new SAML identity provider.
Mapped SAML attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress to Email under Cognito Attribute Mapping.
Enabled the AzureAd identity provider under App Client Settings on Cognito.
Allowed OAuth Flows: Authorization code grant, Implicit grant.
Invited an existing xxx#live.com user to Azure Active Directory and assigned a role to the user in the newly created Enterprise application.
Validated SSO from Enterprise Application > SSO > Validate. It's working as correctly, without any errors.
Problem:
When trying to login via Cognito's login url: https://xxxxx.auth.ap-southeast-1.amazoncognito.com/login?response_type=token&client_id=Cognito-App-Client-ID&redirect_uri=Callback-url-specified-in-cognito-app-client-settings --> AzureAd, I'm being redirected to https://login.microsoftonline.com/... where I enter the added user's email Id: xxx#live.com, after clicking next, instead of a password prompt the page throws a 404 error.
Also tried with inviting another user with email: xxx#mydomain.com, this also results in the same 404 error.
Tried in different browsers: chrome, firefox, safari. All result in the exact same error.
Azure AD SSO SAML2.0 integration doesn't work well with personal accounts.
Integrating with OIDC on the other hand works really well.
Azure AD integration with AWS Cognito.
I am using AWS cognito for authentication purpose.
Every time i hit the cognito domain name it asks me to select the the App client.
Is there a way i can stop cognito asking me to select the Appclient i want to use for authentication.
please do let me know the way
The screenshot that you have posted asks you to select the user with whom you'd like to log in, and it has nothing to do with the App Client. Every App Client of a User Pool works with the same set of users in the pool, but with different authentication settings. If you want to select the App Client for your Cognito Authentication Engine, you can specify the App Client ID in your Cognito Hosted UI Domain. An example URL is as follows:
https://auth.example.com/login?response_type=code&client_id=<your_app_client_id>&redirect_uri=<your_callback_url>
If you specify the App Client ID in your Hosted UI Domain/Custom Domain, you can run your Engine only on that App Client.
The text following after the "Continue with" text is not the app client but your logged-in username.
After you login with your username-password credentials, a session cookie will be set on your Cognito domain to indicate you are already logged in. This session cookie expiration is not configurable and set to 1 hour expiration. The Logout Endpoint removes this session cookie.
When you re-enter the Cognito login page, it will detect you already have a session and present you with the "Continue with" page to confirm that you want to still continue as this user.
If you want to dodge this screen. You can use the Authorization Endpoint which will first check if you have the Cognito domain session, and if you do, automatically redirect you to the redirect uri (application with authorization code), otherwise it will redirect you to the login form via Login Endpoint.
https://COGNITO_SUBDOMAIN.auth.us-east-1.amazoncognito.com/oauth2/authorize?response_type=code&client_id=APP_CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code
Authorization Endpoint: https://docs.aws.amazon.com/cognito/latest/developerguide/authorization-endpoint.html
I searched all over, tutorials, web, everybody jumps away without explaining(I understand why) the checkboxes in app client settings:
Enable sign-in API for server-based authentication
Only allow Custom Authentication
Enable username-password (non-SRP) flow for app-based authentication
The learn more link does not help me, lots of information and not so easy to understand, grasp. Can someone explain this settings?
Here is my take on the matter.
App client has several Auth Flow Configurations.
1. Enable username password auth for admin APIs for authentication (ALLOW_ADMIN_USER_PASSWORD_AUTH)
This enables Server-Side Authentication Flow. If you don't have an end-user app, but instead you're using a secure back end or server-side app.
2. Enable lambda trigger-based custom authentication (ALLOW_CUSTOM_AUTH)
This enables the Custom Authentication Flow. This can help you create a challenge/response-based authentication model using AWS Lambda triggers.
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-challenge.html
Under User Pools -> Triggers you can see many lambda functions. You can use Create Auth Challenge, Define Auth Challenge and Verify Auth Challenge Response functions to create a custom authentication flow.
3. Enable username password based authentication (ALLOW_USER_PASSWORD_AUTH)
This enables Client Side Authentication Flow that uses user password-based authentication. In this flow, Cognito receives the password in the request.
You can use AWS Mobile SDK for Android, AWS Mobile SDK for iOS, or AWS SDK for JavaScript to implement this.
4. Enable SRP (secure remote password) protocol based authentication (ALLOW_USER_SRP_AUTH)
This is similar to the above flow in section 3. except for the password verification. This flow uses the SRP protocol to verify passwords.
http://srp.stanford.edu/whatisit.html
https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_UserPoolClientType.html
5. Enable refresh token based authentication (ALLOW_REFRESH_TOKEN_AUTH)
After successful authentication, Amazon Cognito returns user pool tokens(Three tokens) to your app. You can use the tokens to grant your users access to your own server-side resources, or to the Amazon API Gateway. Or, you can exchange them for temporary AWS credentials to access other AWS services.
The three tokens are ID Token(JWT), Access Token, Refresh Token. The refresh token can be used to retrieve new ID and access tokens. Once you login to a mobile app, you are not needed to log in each time when you close and open the application and this functionality is implemented using refresh tokens.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
What about Amazon Cognito hosted UI ?
App clients can be configured to use built-in Cognito webpages for signing up and signing in users. When using the hosted UI you can enable both the Authorization code grant and the Implicit code grant, and then use each grant as needed.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-app-idp-settings.html
Here is my attempt at explaining these options. Before that I would like to briefly mention about Oauth2, which is the protocol on which AWS Cognito is based.
In the context of AWS Cognito, Cognito itself is the Authentication (OAuth) server and also the Resource server (because we create users in Cognito user pool) and your app would be the Client (which sends the authentication request). The client has to first register itself with the OAuth server - this is what is being done in the "App clients" section of Cognito.
The recommended OAuth2 flow is Authorization Code Grant flow. In this flow,
i) The Client sends username/password to the OAuth Server.
ii) The OAuth server validates and calls back the client with a
authorization code.
iii) The Client again sends this code back to the OAuth server
iv) The OAuth server sends the tokens to the Client.
Please read the above linked article for more explanation on OAuth2.
Now explaining the options in Cognito App Client settings:
1. Enable sign-in API for server-based authentication
With this option, your client app can directly receive the tokens without having the additional step of first getting the authorization code.
There are Cognito APIs like AdminInitiateAuth, Admin-* which does this. However, these APIs require AWS admin credentials. Hence usually these calls are done by the backend server of the client app. The front-end can pass the username/password to the backend and the backend server can communicate with AWS Cognito and authorize the user.
2. Only allow Custom Authentication
Here you don't use the OAuth provided authorization code grant flow. Instead, you can define your own steps and challenges. Your client app can ask a secret question etc, before authenticating and giving tokens.
3. Enable username-password (non-SRP) flow for app-based authentication
This is the least safe flow. This skips the part of returning the authorization code and directly returns the tokens back to the client.
I hope this explains.
I’m currently working on integrating an application using Cognito with external IdPs (ADFS) using SAML. I have done the following steps for my user pool
1)I have created a SAML identity provider by importing the metadata of my ADFS server and enabled the signout flow checkbox.
2)Added the relying party trusts in the ADFS server for my userpool. Configured the singin end point as https://.auth..amazoncognito.com/saml2/idpresponse and logout endpoint as https://.auth..amazoncognito.com/saml2/logout.
3)Imported signing certificate from cognito to the relying party trust signature section.
When I am logging in it is asking for username and password of my Active directory. But During logout the request is going to /saml/logout endpoint and I am getting a successful response. Cognito cookie is getting cleared from the browser. But my ADFS cookies still remains in the browser. Next time When I am logging it my ADFS credentials are getting picked up from the browser. Cognito signout flow is unable to clear the federated IDP's cookies even when sign out flow is enabled. How can I fix this?
although this is not an answer for your question I would like to know how you managed to authenticate users using SAML Idp?
I've setup SAML Idp and enable it in my app client.
I am trying to log in using and android app that has 2 text fields for username and password and a login button.
I get UserNotFoundException. I followed Amazon documentation and cannot find a way to get over it. I'm confused.
Funny thing is that everything works flawlessly when I log in using the auto generated UI by Cognito that is accesses using below format.
Cognito Auto Generated UI
I'm not getting a clear picture of the authentication process when a user logs in through another idp. My use case being for an app that does not need aws credentials.
If I get a token back after a user logs in from facebook for example, how do I connect that with a user in the userpool or my own database which may contain the user's app specific data?
user logs into facebook -> gets token back -> send token to amazon cognito (?) -> get back cognito token (?)
I'm currently looking for documentation on how to implement the above but there doesn't seem to be a direct link to it.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-identity-federation.html
You could setup a social IdP such as Facebook and use the authorize endpoint.
Alternatively, Cognito now supports hosted signup and login pages for your application. You just need to create a Cognito domain, and set App Client Settings.