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
Related
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.
OKTA-Shibboleth(Apache)-Nakisa(Tomcat)
SSO is working for logging-in.
Now, I need to configure Logout. So, user logs out from the app, user needs to be redirected to OKTA page with tiles.
But, currently,user is redirected to the app again.
It's sending user to /logout?redirect=default.html but that default.html is captured by Apache rule and logging user back in.
It looks like it needs to hit
https://xxxx/Shibboleth.sso/Logout. When I access this url, it says logout is successfully done although it's not going back to OKTA. Does that mean that in the App's logout setting, they need to redirect to this?
But, how do I make user to go back to IdP(i.e OKTA) again?
This is what I assume that will happen.
Logout button click > logout from Shibboleth > return to OKTA so user can click other tiles.
Something to configure Shibboleth2.xml?
Document says i just need to configure the following which is there by default.
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
But, how does it redirect user to OKTA(IdP) once user log out completes.
Is it configured in IdP's metadata ?
You can redirect the user after a local logout event anywhere you'd like, via passing the ?return= parameter a URL-encoded destination, i.e. you should update your logout link to:
https://xxxx/Shibboleth.sso/Logout?return=https%3A%2F%2Fgoogle.com
in order to redirect folks to Google once logout has taken place.
Now, you only need an Okta URL to return folks to... so I think if your client's Okta tenant is "foobar.okta.com", redirecting them after local logout to the Okta login page shouldn't prompt them to login, since they will already have the Okta Session... so maybe try:
https://xxxx/Shibboleth.sso/Logout?return=https%3A%2F%2Ffoobar.okta.com%2Flogin
Of course, you'll need to test that... but it should work, and on the off chance that the user's Shibboleth SP session was active, and their Okta session invalidated through some other mechanism, that'll just return them to their regular Okta login page.
You can obviously redirect them to any endpoint with the return parameter, for example, whatever Okta's logout URL (if you wanted to kill their Okta session too).
The only logout that's configurable by Metadata is SLO (single logout), i.e. if you wanted it to, Shibboleth can redirect the user to Okta after they complete the logout of the SP session, along with a specially-craft <LogoutRequest> assertion payload, which Okta would parse and act on in any number of ways, i.e. killing the user's Okta session, propagating Okta-initiated subsequent <LogoutRequest> assertions to other Service Providers, etc. In practice, this never really works, because such configurations are very difficult to get working between all of the relevant parties.
Flow:
on angular front-end (FE) there is a call to create a user, first I create a user in my identity server 4 (IS4) runing on .net core.
from there is4 makes a request to b2c graph api to create a b2c user, and gets a success response
after the success response i send the email to the user with the link to continue the onboarding process
user cliks link, autoredirects to b2c, which auto redirects to is4, user puts in credentials, goes back to b2c and ends up on create b2c user page instead of redirecting back to FE
if i only click continue on b2c signup page it says "You are already registered, please press the back button and sign in instead."
if i click the link in the email again, everything works fine
This bug happens only once in a while, and I assume that the b2c user, although created is still not ready for use. If I disable signup part of a custom user flow, the app keeps redirecting for a few seconds getting the error in address bar
error=server_error&error_description=AADB2C90037:+An+error+occurred+while+processing+the+request.+Please+contact+administrator+of+the+site+you+are+trying+to+access)
AADB2C90037 error is for missing objectId
After a few redirects it finally finds the b2c user, and after that everything works fine.
Does anybody know how I can make sure b2c user is ready for use, before calling the signin process?
I have created sign in policy in my azure active directory B2C tenant and trying to retain user credentials. On my login screen there is one checkbox "Keep me sign in" which is not working. Even if I check keep me sign in checkbox, I am not able to retain user password on IE, Firefox browser. However this is working for Chrome only because it retain user credentials by default.
Please suggest me how can we overcome this problem. Can we retain user credentials on AADB2C sign in page?
I have created new signin policy in azure ad b2c and use this policy for sign in page. Sign in policy has "keep me signed in" functionality by default. We dont need to write any code. Browser will take care of session management. Whenever we mark"keep me signed in" checkbox check, browser stores user credentials on browser and we do not need to re-enter password again. It will redirect to our page.
Thank You,
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