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.
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
My Auth Server uses IdentityServer4.
Redirect configured as follows for a client
RedirectUris = new List<string>
{
"https://localhost:44342/signin-oidc"
}
this works fine for those users for whom MFA is not enabled. But when it is enabled, and kicks in, the redirect doesn't work. After successful 2nd FA, user stays back on the AuthServer page.
Any idea why?
Multifactor authentication is not implemented by Identityserver4. Identityserver4 is about how the third party application gets access to protected resources on behalf of the user.
The means of how the user gets authenticated are out of the identityserver4 scope. In other words, this is not related to identityserver4.
If you're using the identityserver4 quickstart it comes with ASPNET Identity, ASPNET Identity provides you with a local authentication system for ASPNET applications. MultiFactor Authentication is probably there.
Being said that, when you try to POST to the /authorize endpoint (note authorize not authenticate) from your client application IdentityServer tries to authorize your request and to do so it makes you authenticate first, by presenting you the Login Form.
If you look at the Address bar on this point, you'll notice there's an encoded url as returnUrl param, on the controller code you'll see a check that if that param is present, redirect to that url after successful login.
So, check the flow on your application and see where does that parameter get lost on the redirect hell, at some point you're not passing the returnUrl.
I'm trying to implement Authorization Code Flow for SPA React client with ASP.NET Core and IdentityServer4.
There are two scenarios:
1) User open SPA app, we check if he has an access token and if he hasn't we generate url like
/connect/authorize?
client_id=*client_id*&
redirect_uri=*redirect_uri*&
response_type=code&
response_mode=fragment&
state=*some_state*&
nonce=*some_nonce*&
code_challenge=*code_challenge*&
code_challenge_method=S256&
scope=openid profile email
And so Authorization Code Flow starts. This works pretty clear and after all round trips user comes back to SPA app with code then send request for token (include code and code_verifier) then receive it and with happiness in soul continue using our great application.
2) User opens login page directly and here is where I'm stuck. IdentityServer context knows nothing about this user, code challenges etc. because we didn't make request to /connect/authorize before going to this page as in normal flow. What's next?
I can generate /connect/authorize link directly in login page and do ugly redirect to it and then back to login page (what I don't want to do honestly), but how my SPA app will know what code_verifier I generate here? Of course I can store it in some shared cross-domain cookie, but here should be something better approach I believe.
Another solution I can redirect user from login page to my app, it recognizes that user not authorized and we start scenario #1. Also not my go to approach I think.
What should I do in case user opens my identity server page directly?
Is this possible using Authorization Code Flow or should I consider combine some other flows with this one?
I don't want to use Implicit Flow due to new recommendation from OAuth 2.0 specification.
Quite a simple answer to this - in your second scenario - if your user opens IDP login page directly, they didn't want to go to your app. It's the same if you were using Google or Facebook or one of the other known IDP's for your SPA and as a user I just went to their login page instead. They couldn't possibly know if my intention was to ever come to login so that I am later redirected to your SPA.
Now having said all that - what you could do to make this work somewhat seamless - is to redirect to your SPA's protected page after the user logs in through Identity Server 4 (that's simple because you own the login pages and there is no OAuth involved here). Your SPA would then be triggered to initiate the OAuth2 flow and would redirect back to Identity Server 4. The user has already logged in just seconds ago here though, so the login procedure would be skipped and user would either be presented with consent page or if your client is configured to skip consent page - user would be redirected back to your SPA with the usual tokens and such.
So to break it down into the flow:
User Accesses IDS4 Login Page -> User Enters Credentials -> IDS4
Authenticates User and Redirects to your SPA protected page -> Your
SPA initiates OAuth2 flow and redirects back to IDS4 -> IDS4 displays
consent page -> IDS4 issues auth code back to your SPA.
There is ofcourse extra step here that your SPA will exchange auth code for access token, but I omitted it for clarity purpose as it's not relevant to the question.
I've been learning Auth0 for a React / React Native project. With two different apps now, including one from their site, I see the following behavior:
clear browser cache
login
enter password, now logged in
select logout
--> now logged out
select login
am NOT prompted for password again, just logged in without interaction.
It seems the session has been kept alive even though I logged out. I would expect that if I manually log out of an application, I must re-authorize with my password on the next login attempt.
As I said I've seen this twice now, once with my own project and once with the tutorial they provide at https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/ . Doesn't make any sense to me. Am I missing something?
Thanks ~~
This is the Seamless SSO behaviour explained here. This is now enabled by default on all tenants and it "seamlessly" logs the user in without showing any prompts if a session exists for the user in the Authorization server (Auth0 in this case). Previously you would get a prompt that said "Last time you logged in with ..." Clicking it would login you in without requiring a password.
If you are "Logging out" and yet you can log back in again without needing to enter credentials, the most likely explanation is that you are actually not calling the https://YOUR_AUTH0_DOMAIN/v2/logout endpoint which logs out the user by clearing their SSO cookie in Auth0. You can confirm this endpoint is called from Network tab in your browser when you click to logout.
The Auth0 React quickstart by default does not call the logout endpoint, it only removes the tokens from browser storage. To clear the SSO cookie and logout from IdP using Auth0.js you need to call the logout function as well. Refer to the Auth0.js logout function here.
Hope that helps.
We have a B2C custom policy for authentication but I am having trouble getting a consistent complete logout. The only way I have been able to get a complete logout of single sign on is to use the common endpoint:
https://login.microsoftonline.com/common/oauth2/logout?post_logout_redirect_uri={our homepage}
Then when I login I see this
Then I click sign in and see this
but even this does not always work. Sometimes it does not redirect but just sits on the "you have been logged out" screen.
Using the logout endpoint given in our metadata endpoint does not work as expected. I see the sign in screen (first image) but I cannot choose which account to login with I just click the button to sign in. I assume this means single sign on logout has not worked.
https://login.microsoftonline.com/te/{tennant}/{b2c-policy}/oauth2/v2.0/logout?post_logout_redirect_uri={our homepage}
How can I either get the first one to work every time or the second one to logout completely?
EDIT: Sorry I should have mentioned I am using node.js/javascript but any url type solution will work also. Also we are using B2C so the application is registered on that tenant. There is no option for a lotout url on this page.
In order to logout the user from B2C, you need to redirect your user to the B2C logout endpoint, not to the common endpoint. This should look like:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_sign_in&post_logout_redirect_uri={your homepage}
Be sure you redirect the browser to that endpoint and don't try to do a GET through a back-channel, otherwise it will not do anything as the Single Sign-in mechanism is based on browser cookies.
Reference: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oidc#send-a-sign-out-request
If I understand you correctly, you are trying to configure single sign out? This can be done but requires configuration separate from the sign-on configuration.
In the Accounts Controller you need to add a SingleSignOut action.
public ActionResult SingleSignOut(string redirectUri)
{
if (redirectUri == null)
ViewBag.RedirectUri = "https://localhost:44308/";
else
ViewBag.RedirectUri = redirectUri;
HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
return View();
}
See this tutorial and the accompanying repository.
This reference is also helpful.