i am trying to set AWS Cognito as Auth provider to log in salesforce.
I have set up an "Auth Provider" (called it Cognito) enabled it as login option both for salesforce login and for community (in community workspace).
Auth provider settings
When i try to login to salesforce using Cognito credentials i manage to do it without issues, but when i click on "Cognito" as a login option in my community i get an error even before i try to enter my credentials:
Trying to log in
Error and url string
I use different credentials for user that is internal and user that is external, although in case of community login i did not even manage to enter my creds. In url string i see that error is "redirect_mismatch" but i am not sure what that means in current context and how to resolve it. In my Registration helper i have only adjusted "createUser" method to return a user that i already have in my org:
global User createUser(Id portalId, Auth.UserData data){
return [SELECT Id, Name, ContactId FROM User WHERE FederationIdentifier = :data.email];
}
If someone has experience with using Cognito as auth provider for salesforce communities i will be glad for any help.
Redirect mismatch is referring to your callback URL being different than the one you defined in your user pool settings. Go to user pool settings and click on app client settings. Here you will see fields for sign in and sign out urls. Put in the correct callback/redirect url here. You can enter multiple urls separated by commas.
Related
I am using Azure AD with React JS. When I am signed in using multiple accounts and call msal logout, then it is showing me an option to select an account that needs to be signed out. I just want to show the logout option for the currently active account, rather than all signed-in users.
I have tried to pass an active account using the below snippet but still, I am getting an option to logout all signed-in accounts. Can you please let me know how can I get an option to logout only active account, rather than all signed-in accounts?
const myMsal = new PublicClientApplication(config);
// you can select which account application should sign out
const logoutRequest = {
account: myMsal.getAccountByHomeId(homeAccountId)
}
myMsal.logoutRedirect(logoutRequest);
https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-sign-in?tabs=javascript2#sign-out-with-a-redirect
You can use Prompt-less Logout:
const currentAccount = msalInstance.getAccountByHomeId(homeAccountId);
// The account's ID Token must contain the login_hint optional claim to avoid the account picker
await msalInstance.logoutRedirect({ account: currentAccount});
You will need to add login_hint claim to token optional claims in your application's Token configuration on Azure Portal:
msal logout it is shows an option to select an account that
needs to be signed out
The logout prompt you're seeing comes from the AAD service, because it needs to know which user to terminate the session for on the authentication server side
Unfortunately, this is a known issue with the AAD service. At this time, there is no way to bypass the logout account selection screen on logout
According to this document : https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/logout.md and code descriptions, MSAL is clear the cache and session data on the client side (browser)
There is github issue you can refer it for more details :
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/2922
I have 3 applications:
An IdentityServer4 API which provides Google authentication and also provides an access token to authorize the resource API.
A simple Resource API which provides some data from DB.
A simple Client in React which have 4 buttons:
Login, for Google auth
Logout
Get data - a simple request with the access token to the Resource API and gets the data from Db
Get user data - returns user profile and token (for debug purpose)
I didn't put any sample code because my problem is not code related, it's knowledge that I'm missing and I ask for guidance.
The workflow is working just fine: the user press the Login button, it is redirected to IdentityServer4 API for Google Auth. From there it is redirected to a Callback Page from the Client and from there to the Index page. I receive the user data and the token, I can request data from the Resource API and it's working.
My problem is: How do I give a Role to the Google Users ?
I don't have users saved in DB. I want three types of Users: SuperAdmin, Admin, Viewer and each of these roles have limited Endpoints which can access.
For limiting their access I saw that I can use Claims-based authorization or Role-based authorization.
So, my question is how ca I give a Google User who wants to login in my app, a specific Claim/Role ? What is the workflow ? I must save it first in DB ? Or there exists a service from Google where I can add an email address and select a Role for that address ?
Thank you very much !
After you get the response from Google in your callback you can handle the user and do what ever you want to do with it. Below are the some typical tasks that you can do in callback that I took from documentation page of identityserver4 link:
Handling the callback and signing in the user
On the callback page your typical tasks are:
inspect the identity returned by the external provider.
make a decision how you want to deal with that user. This might be
different based on the fact if this is a new user or a returning
user.
new users might need additional steps and UI before they are allowed
in.
probably create a new internal user account that is linked to the
external provider.
store the external claims that you want to keep.
delete the temporary cookie
sign-in the user
What I would do is creating an new internal user account that is linked to the external provider and add a role to that user.
If you don't want to save users in db, you can add an extra claim to user in callback method and use that claim in token. and i think this link will help with that.
The disturbing scenario is: users log out of the application but their session remains valid such that they are able to sign back in without reauthenticating. Is the below code snippet the portion of the code that needs to be configured for the B2C session behaviour?
app.UseRewriter(
new RewriteOptions().Add(
context =>
{
if (context.HttpContext.Request.Path == "/MicrosoftIdentity/Account/SignedOut")
{ context.HttpContext.Response.Redirect("/Home/Index"); }
}));
When you want to sign the user out of the application, it isn't enough
to clear the application's cookies or otherwise end the session with
the user. Redirect the user to Azure AD B2C to sign out. If you fail
to do so, the user might be able to reauthenticate to your application
without entering their credentials again
The logout endpoint can receive an optional post_logout_redirect_uri parameter in the query string, where you can specify another URL where your user will be finally redirected by B2C. That can be the address of any resource, e.g. you homepage or your own page showing a "You successfully logged out of our service" message to the user.
post_logout_redirect_uri - The URL that the user should be redirected to after successful sign out. If it isn't included, Azure AD B2C shows the user a generic message.
For more details refer this document And also check with this SO Thread
I have setup my GSuite account as a SAML iDP for Cognito User Pools (not identity pools).
If i provide no attribute mappings a new user trying to signup via GSuite login gets the following error.
Error in SAML response processing: Invalid user attributes: email: Attribute is required.
However if I add an email mapping, the user can signup. But can't ever sign in again as they get this error (strange as email is writable by this app client)
Error in SAML response processing: Invalid user attributes: email: Attribute cannot be updated.
Ideas as to whats going on?
In browser, using Hosted UI.
It turns out I had made the email address immutable during CloudFormation setup. Even though the email is not being modified, it needs to be mutable.
You can determine the mutability of email via the following command.
aws --output table cognito-idp describe-user-pool --user-pool-id <user pool id> | grep -B6 -A7 " | email "
For anyone who is facing this issue when using SAML and AD as the identity provider, you have to configure Attribute Mapping.
Go to Attribute Mapping under Federation, Enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress for SAML attribute and Select Email fro User pool attribute
I had the error below randomly after being able to login the first time. Disabling and then deleting the user from the pool and allowing Cognito to recreate it fixed the issue for me. I assume there is an AWS bug here somewhere.
Error in SAML response processing: Invalid user attributes: email: Attribute cannot be updated.
I have set up the custom login page for my application using the following resource.
http://brianpeddle.com/2011/06/06/building-a-custom-salesforce-login/
However this approach requires security token for each user if the user is in untrusted network and the security token changes when user reset password.
How can I set up so that I allow multiple user login from this page? Currently only I can think of is have an extra input box so that user past the security token along with username and password. I wonder if salesforce allow javascript to grab security token dynamically for each user
OAuth2 is a security implementation that allows users to access their Salesforce data without having to enter their user/password in an untrusted application or do nasty token management themselves.
Salesforce has a guide on how to implement OAuth2 for web sites. It can be difficult to set up if you don't have any experience with OAuth2, but there are plenty of guide available.
I would also recommend using something like Firefox's RESTClient addon (or something like it) to test the use of OAuth2 to get a feel for authenticating against Salesforce .
Are you sure you have white listed the IP?
I strongly belive if you get the IP of server where your custom login page is hosted and put that in list of white listed IP's then User will not required to enter their security token.
to find the ip of your server(where your page is hosted)
- try to login with your custom login page
- login into SFDC and go to setup -> user profile-> login history
there you will see last login from IP
Copy above IP and
Again go into Setup -> Security control -> Remote site setting
and add above copied IP.
this way SF will not required security token when user is login from that IP.
http://ap1.salesforce.com/help/doc/en/configuring_remoteproxy.htm
Use this code for just login:
https://login.salesforce.com?un="+username+"&pw="+password+"&startURL=/apex/somepage