When someone goes to link their social media account to their ADB2C registration, we have a problem whereby we are unable to distinguish between a failed ADB2C sign in, and the cancellation of their request to link their social media account.
When someone, for example, tries to link their Facebook account, a URL like this sits behind the 'Not now' link:
https://test.b2clogin.com/test.onmicrosoft.com/oauth2/authresp?error=access_denied&error_code=200&error_description=Permissions+error&error_reason=user_denied&state=StateProperties%3DeyJTSUQiOiJ4LW1zLWNwaW0tcmM6NzMyYWQzZWXtZGI4OS00YjZiLTlmYzgtYTY5NzYxZDdjMDY0IiwiVElEIjoiNTcxZWE5M2UtODQ4NS00MTMzLTlhZmItOTQwMWIyMDAwOGE5IiwiVE9JRCI6Ijc4ZDUxNTY3LTkzYTAtNDEyMy1iMHI1LTVmN2E1NzNjMzRkYSJ9#_=_
We trap the AuthenticationFailedNotification, but within it, we haven't been able to find a way to distinguish between
an access denied message based on the cancellation of the request to link a social media account, and
an actual genuine access denied response.
We check:
if (notification.ProtocolMessage.Error == "access_denied" && notification.ProtocolMessage.ErrorDescription.StartsWith("[A SPECIFIC ERROR ID]", StringComparison.InvariantCultureIgnoreCase))
We would then have a specific user flow configured for each scenario, based on the error description, authentication policy and authentication type (social media or ADB2C).
Our requirement is for the user to remain logged in to ADB2C when they attempt to link a social account, but don't actually go through with it.
Microsoft's own example, https://woodgrovedemo.com/ works in the same way, whereby the user is logged out when they cancel the linking of their social media account (for example, by clicking 'Not now' when going to link their Facebook account).
You can't, because it's the same thing!
When a user cancel the Facebook process with the 'Not now' button, the user ain't logged in. You need the user to accept to be link to your app for Facebook to send an approbation and a claims to be delivered to your app. Without this claims, the user is not logged in.
So you can't have a requirement to keep the user logged in, since he haven't been logged in yet. It's false to think that the Microsoft's example logged out the user, since he was never logged in.
Related
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 am using MS Graph in a desktop application so I am hosting a web browser in a form for the user to do their initial login. This all works fine and I can fully use MS Graph.
The problem I have is if we need to use an account of a different user there does not seem to be a way to reset the login. If you try to login again with the hosted web browser it will go right through and allow the same user.
The only way to reset it for another user seems to be to go into IE and delete the history/cache. Then the login screen will ask a user to login again. It seems a bit extreme to reset the cache.
So is this the only way to do this or is there something I can change in the MS Graph API call to tell it to reset?
You can force re-authentication by added prompt=login to the sign-in request:
Prompt (optional)
Indicates the type of user interaction that is required. The only valid values at this time are login, none, select_account, and consent.
prompt=login will force the user to enter their credentials on that request, negating single-sign on.
prompt=none is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform endpoint will return an error.
prompt=select_account sends the user to an account picker where all of the accounts remembered in the session will appear.
prompt=consent will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.
I have set up identityserver 4 with an asp.net mvc web site using it for authentication (implicit grant type). I need have to have the claims on token updated when the user modifies the profile of the account but it is not.
Everything is working great in the happy path, client authenticates, then redirects back to website, claims comes through - all good.
My web site has a link that sends the user back to the IdentityServer in order to update the profile (name, email, phone, etc) but once this is completed and the user is sent back to the web site the claims are not being updated with the new information.
I can see that my user claims factory is being called from the profile service and that the new profile information is being set in the claims, however my website doesn't seem to pick up the new information. What might I be missing? Is this even the correct approach?
After the user logged in claim information is saved in a cookie. It will not be updated until the user logs out and logs in again. You may need to sign out user forcefully so that he must log in again after a profile update.
But if the user does frequent profile updates you may need to rethink having profile data in id-token and then in claims. There is a user info endpoint in identity server that you can query to retrieve profile data when needed.
http://docs.identityserver.io/en/latest/endpoints/userinfo.html
We're working on a SAAS application that has recently been configured to use Azure ADAL for authentication. If it matters, we're going the oauth2 route, with response_type: code.
However, when we're testing the application, if the browser has been signed into an Azure account that does not belong to the tenant acting as identity provider, the prompt for password is bypassed, and the login fails on the Azure screen, saying AADSTS50020 - user not found in tenant.
On the one hand, congratulations to Azure for finding an already signed in user! On the other hand, there is no recourse to elect to not use this signed in user; it does not give the user the chance to interject with credentials that work.
How can we prevent this?
The core issue is we don't want users, visiting our site and ready to sign in, to have to have already signed out of Azure before trying to log in with our site.
Thanks in advance.
Please refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
You could find when requesting an authorization code during code flow , there is a Parameter :prompt indicates the type of user interaction that is required .
Valid values are:
login: The user should be prompted to reauthenticate.
select_account: The user is prompted to select an account, interrupting single sign on. The user may select an existing signed-in account, enter their credentials for a remembered account, or choose to use a different account altogether.
consent: User consent has been granted, but needs to be updated. The user should be prompted to consent.
admin_consent: An administrator should be prompted to consent on behalf of all users in their organization
You could use prompt=login forces the user to enter their credentials on that request, negating single-sign on
I have SAML service provider(SP) and I want to use salesforce as a Identity provider(IdP) with my SP.
I have setup domain, Created new Connected App with saml enabled with all required details. Then downloaded metadata and used this to register on SP.
Salesforce gives me IdP initiated Login Page URL. When i visit that, it works perfectly. It redirects to saleforce login, after that sends SAML response to SP. But when I visit SP and initiate login from there which redirects to salesforce page which gives following error.
Insufficient Privileges
You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary.
I had the same issue and got fixed. Here are helpful tips.
You can check on the logs under 'Manage Users -> Identity Provider Event Log'. This could give reason for your error. I got a 'Error: User does not have access to this service provider' error
For this, the user was not given permission. Even if the user is System Administrator, the access to Connected App is not given by default. To give permission, go to 'Manager Users -> Users' and click edit on the user you are testing.Click profile name link .e.g System Administrator. This takes to profile page. You can scroll below to 'Connected App Access' and you would see that the access is not given. Give the access by clicking edit profile in the top of page.