I've got an MVC5 app defended by JWT Tokens from ACS.
Unauthenticated users are redirected to the ACS login page, where they select an IdP and enter their credentials. They are redirected back to my MVCApp with a JWT Token thats authenticated using the Microsoft JWT Token handler. Beautiful!
I want to re-use my token, passing it my web API, added saveBootstrapContext="true" to the identityConfiguration node in my web.config
However, the ClaimsPrincipal.Current.Identity.BootstrapContext is always null.
How can I capture the bootstrap context to fetch the token?
Killing my chrome session and whacking my cookies seems to have alleviated this issue. I'm not getting a Bootstrap Context value.
Related
I'm using keycloak 4.3.8.final.
I want to utilize keycloak's OIDC flow with my own IDP. I don't want to use any session related capabilities from keycloak, only the authorize adn token endpoints.
All good, when user hits keycloak's authorize endpoint, get redirected to IDP, login, then get redirected back and then get token from Keycloak.
But when another user performs the same authorize/token scenario on the same browser, right away after the first one, with passed parameter prompt=login, keycloak instead of returning another token, throws the following error:
You are already authenticated as different user <placeholder> in this session. Please logout first.
Seems that even when passed prompt=login, keycloak still checks for valid session. Does anyone had the same problem as me? Does anyone has solution for the problem?
Thanks
I am reviewing OKTA. I have two authorization servers configured, the default one and a custom one. I have a client (web app) that is configured and correctly logging in. I am getting back the expected id_token and access_token. The problem I am running into, is how do I call an api, that is expecting an access token from the second authorization server? How do I request an access token on behalf of the logged in user (default auth server) from the second auth server, without prompting the user to login again? This is all done in .net core mvc application.
In each of your applications you can check for an active Okta session. If found initiate the OIDC AuthN flow.
This is the endpoint on the client you can use to check for an Active Session
https://developer.okta.com/docs/api/resources/sessions#get-current-session
You can use the following authorize URL to get the access token or id token
{{url}}/oauth2/{auth server ID}/v1/authorize?client_id={client id}&response_type=token&response_mode=fragment&scope=openid&nonce=nonce&state=state&redirect_uri={redirect url}
Get the auth server ID from the URL when you see visit the server in the UI.
The above call needs an active session so if you signed the user the first time with 'default' auth server recently. You don't need to sign the user again to get to the token for the second auth server.
I have an Asp.Net MVC 5 web application that uses OpenId Connect via Azure AD to manage user authentication. I think I understand that once authenticated, the auth token is valid for one hour at which point the OWIN middleware will handle refreshing the auth token in the background without the user having to be redirected to the login page and re-enter their username/password. I have observed this by watching the address change in the address bar of the browser after the auth token expires.
My problem is that I have form that users stay on for a long time (60+ minutes) while they are doing interviews and entering in data. The auth token expires and when the user tries to submit the form the auth token refresh happens in the background and the form is never posted to my application. Instead, the view is refreshed (from the HTTP GET that happens after the auth token is refreshed) and the user loses all of the data they've collected over the last hour.
Is this the expected behavior or do I have something configured incorrectly?
we are implementing a Single Sign On process using WSO2 Identity Server. We have both Microsoft and Java web applications involved and we are facing a problem during the Single LogOut processing with Microsoft based web apps. The issue is related to session invalidation on Identity Provider initiated SLO.
This is the scenario:
WSO2 Identity Server with a single Identity Provider configured
an Asp.Net MVC application using ComponentSpace SAML2 assembly and Forms authentication marking controllers with the [Authorize] attribute to ensure that users are authenticated to access them.
the DEMO Java Web application provided by WSO2 to test SSO
The login process works fine. We get a session ID from WSO2 and the user is authenticated landing on WSO2 login form in the first app, and transparently in the sencond one.
In the Asp.Net webapp, when a successfull login occurs, we authenticate the user to access [Authorize] marked controllers calling FormsAuthentication.SetAuthCookie(userName, false); . When the user logout from one of the apps, WSO2 sends a SLO request to other partecipants on a configured URI. When this request is reveived by the Microsoft one, we call the FormsAuthentication.SignOut(); method but the session is not destroyed. If the user refresh the browser page its User.Authenticated property is still True so he can still access [Authorize] marked controllers. This makes sense in my opinion because the caller is WSO2 and not the user browser.
We performed some investigation in the code of the JAR provided by WSO2 for Java applications and it creates a filter on Tomcat implementing a singleton to store WSO2 Session ID relation with Session objects each time a success login operation occurs. When WSO2 request a SLO the filter gets WSO2 Session ID as parameter, accesses the singleton HashTable to retrieve the Session object and calls the Session.Invalidate() method of the session object. If the user refreshes the browser, he gets redirected to login page. We tryied to implement something similar on Asp.Net side but even if we get the Session object on server side and call the Session.Abandon() method nothing happens when the user refresh the browser. He is still marked as authenticated.
I am not very familiar with Cookies and I have the feeling that is something related to them.
Had anyone faced a similar issue?
Any advice or suggestion will be very appreciated.
Thanks
Calling FormsAuthentication.SignOut should clear the authentication cookie. I suggest capturing the HTTP flow and confirming whether the authentication cookie has been deleted. The default name for the authentication cookie is .ASPXAUTH. Alternatively it will be the name specified in your web.config's section. For example, forms name="mycookie" would rename the cookie to mycookie. You shouldn't have to delete the ASP.NET_SessionId session ID cookie.
Correct me if I'm not understanding something. I'm working with a fresh Web API application generated from a VS template.
The user does register right on the login page of the Web API app.
It appears that a user can register from outside the Web API app (from ANY device that knows the api/Accounts URL), but it requires passing sensitive information in plain text.
The sample ValuesController has the [Authorize].
Accessing /api/Values from the browser will throw a 401 if the user is not logged in.
Accessing /api/Values from Fiddler will also throw a 401 even if the user is logged in. This is because it requires an Authorize: Bearer header, which the access token isn't available from outside the web application.
There is a token endpoint that we can use to request a token from outside the app, but using the built-in token endpoint requires the user's username and password as plain text to be sent.
I guess all the work needs to be done from an external trusted client application (which must have access to the same database that stores user info). From the client application, how would I create an access token so that I can make a request that would have that access token in the header?
Suppose that I was able to achieve generating an acceptable access token from the client. Will the [Authorize] attribute still block access because the user would technically not be logged in? Or does [Authorize] actually log the user in if it doesn't result in a 401?
The AuthorizeAttribute will block access when the IsAuthenticated property of the current IIdentity is false. This is entirely separated from the access token.
Your steps are all right. But i think you are mixing you understanding of the last part with cookies authentication and token authentication.
Will the [Authorize] attribute still block access because the user
would technically not be logged in? Or does [Authorize] actually log
the user in if it doesn't result in a 401?
With cookie authentication this would be a problem that the user would technically need to be logged in and a valid session would need to exist on the server.
However this would not be the case on with token authentication. As long as you have a valid bearer token, you may access the api from any device.