I am trying to create a session using pre-existing cookie. However, dont seem to find any way to configure micronaut application.
Ideal flow
Browser calls a rest API
Server detects no session (Unauthenticated)
Request is intercepted and login is performed thro' a call to an external system using the passed in cookie.
if success, Request continues to rest resource and return the result
if fail, return 401
I dont seem to find a way to intercept the request and authenticate on the fly.
Tried to work with Session and idToken but not sure if those are right options. Also, tried to override SessionSecurityfilterRejectionHandler without any luck.
Related
I need to perform one app that is signed in via login.microsoftonline.com, but I get this error "We can`t sign you in your browser is currently set to block cookies. you need to allow cookies to use this service." maybe someone else has experienced something similar.
I tried changing HTTP Cookie Manager type from standart to others, also I used CookieManager.save.cookies with true and false but nothing worked.
HTTP Cookie Manager
request
error
You're not supposed to have the request to login.microsoftonline.com as the very first request in your JMeter script.
My expectation is that you're trying to test an application which uses Microsoft Identity Platform as authentication provider so depending on your application auth flow you need to pass some parameters to this login.microsoftonline.com page and the parameters need to be extracted from the previous request.
So try starting with your application login page and I believe you should be redirected to the login.microsoftonline.com with valid cookies and appropriate parameters
I'm currently trying to implement silent refresh follow this workaround
However, even when I'm logged in, if I try to do an AJAX GET request to the oauth2/authorize endpoint, I get a status of 200. I tried going to the URL in the browser directly, and it worked. Do I need to pass additional information?
Any help would be greatly appreciated, thanks!
I ended up solving my own problem and was able to not have to use an iframe.
Solution to original problem (I was using authorization code flow):
Set up an endpoint on your server with a silent response that FusionAuth can redirect to (endpoint 1).
Set up an endpoint that you will call from your app to perform the silent refresh (endpoint 2).
From the app, send AJAX GET request to endpoint 2.
On the server side of endpoint 2, send AJAX GET request to FusionAuth with redirect_uri=(endpoint 2)
On success, get redirected url. (In express.js with axios I did response.request.res.responseUrl)
If the url is current server host and not the fusionauth service host, complete auth code flow. Return the token and tell the browser that the user is logged in.
In all other cases the user is not logged in, so return to app that user is not logged in.
When using the Postman Chrome App with the Interceptor extension it's easy to reuse the browser's cookies in order to log into an app and then call the services within.
Since moving to the Postman standalone app, this process has become somewhat manual. After logging in from the browser, I have to access the JSESSIONID cookie in the developer tools and copy its value over to postman.
When my session expires I need to repeat the process.
I would like to automate this synchronization or at least understand how I could obtain the new authenticated value in postman. It's important to note that none of the authentication mechanisms available in Postman work with my app which is why the manual login in the browser is necessary.
You can get JSESSIONID cookie in Postman Standalone in similar way your browser do it - by send proper requests (probably POST "login" request with user credentials) to server
I'm using Glassfish 4 as a server with an AngularJS app as a client. Glassfish is exposing a REST API via JAX-RS (Jersey). I'm using Basic Authentication over an HTTPS connection. I have my own login form and am setting the Authorization header in my REST requests via JavaScript. My issue is that if I use normal web.xml based permissions (<auth-constraint> inside <security-constraint>), the responses come back with 401 with a WWW-Authenticate header (if the credentials are bad). This forces the browser to do the Basic Authentication dialog instead of my own and it appears there is no viable cross browser work around available on the browser side to stop it. So I need to somehow suppress the 401/WWW-Authenticate response.
I stopped using the web.xml based permissions, because it seems it is the Servlet level that is doing the 401 stuff. I was able to get Jersey authentication working with a filter and turning on the "RolesAllowedDynamicFeature" feature (in a matter similar to Glassfish #RolesAllowed with custom SecurityContext). That seems to work great and returns 403 for bad credentials (and thus no browser dialog). However, when I call my EJB's, they do not see the custom security context and the user I have set, so I get permission exceptions. If it matters: the EJB's are in a jar, the Jersey stuff is in a war, and both of them and bundled together in an ear. From what I can gather the only way to have the EJB's properly process credentials is to use the web.xml stuff.
I seemed to have painted myself into a corner and do not see how to make this work. Perhaps I can back out and return to using web.xml based permissions and somehow filter the servlet responses to not return 401/WWW-Authenticate? If so I could not find out how to do that. Or is there some way I can set EJB's security context? Or something else entirely? I wouldn't think using AngularJS with GlassFish and a REST API and Basic Authentication would be very unique, how does anyone do this?
Since posting this question I have found info on implementing a Servlet filter and using that to try to change the 401 response to a different status code. However, the filter never gains control if you have <auth-constraint> in your web.xml and the request is not authorized, so that did not help me. I still could not prevent the 401 responses.
But now I think I finally found the answer. I removed the <auth-constraint> tag from web.xml. I changed the Servlet filter to now extract the AUTHENTICATION_HEADER on its own and decode it (via javax.xml.bind.DatatypeConverter). Next I call HttpServletRequest.login (on the request object) with the decoded username and password. I catch the ServletException if the username/password combination is bad and use HttpServletResponse.sendError to send SC_FORBIDDEN. If I have a good login I call doFilter to continue on with processing of the request, and call HttpServletRequest.logout when it returns.
If I do this in combination with RolesAllowedDynamicFeature and annotations on the Jersey routines everything seems to work including calls to EJB's with their own security annotations.
Side note: before settling on HttpServletRequest.login I had tried to use HttpServletRequest.authenticate followed by checking the returned boolean, but when you gain control in that case the response has already been committed to be 401 and you cannot change it. I even tried passing a HttpServletResponseWrapper to authenticate to stop the commit from happening, but authenticate seems to get the response object through some other means, it seems to ignore the one you pass it (I even tried passed null and it didn't even notice).
I have a test application that accesses two Adapters:
A JavaScript adapter protected by a SecurityTest referencing a realm
A Java adapter with a method protected by an OAuth scope corresponding to that same realm.
If I follow this sequence everything works as expected:
Attempt to access the JS adapter, I get challenged, authenticate, get data.
WL.Client.isUserAuthenticated() and WL.Client.getUserInfo() now behave as expected
Logout using WL.Client.logout()
WL.Client.isUserAuthenticated() now shows I'm not authenticated
A second attempt to access the JS adapter causes another Challenge, as expeccted.
However, with the Java Adapter logout() seems not to behave as expected.
Starting with no session, attempt to access the Java adapter, the challenge happens as expected and I get to my data
I can now access the JS adapter without further challenge and the WL.Client.getUserInfo() calls gives the expected results.
WL.Client.logout() appears to work, in that WL.Client.isUserAuthenticated() now shows I'm not authenticated
But a call to the Java adapter still works without further challenge
A call to the JS adapter does result in a challenge
If I'm running in my browser simulator environment I can destroy the OAuth session by using this command:
localStorage.removeItem("com.worklight.oauth.idtoken")
The question is:
Should the WL.Client.logout() method have destroyed the OAuth session? If not what API should I be using?
With OAuth, logout 'works' differently. See the following user documentation topic (search for "logout"): http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_model.html?lang=en
The login/logout API:
The WLClient login/logout API enables a user to
log in to and log out of a specific realm, by updating the server side
security state. However, in the new OAuth-based security model,
security credentials are also kept in the access token on the client
side. The result is that using this API will cause an inconsistent
state, for example, in which the client is logged out of a realm on
the server side but still holds a valid token for that realm on the
client side. To solve this inconsistency, it is recommended to
re-obtain the access token, by using the
obtainAuthorizationHeaderForScope method, after successful login or
logout.
For example, consider a client that passed the security checks for
Realm1 and Realm2, and later calls logout(Realm2). In this case, the
access token on the client would still contain the security
credentials for both Realm1 and Realm2, and the client could use this
token to access protected resources. To refresh the token, that is, to
obtain a token for Realm1 only, the client calls
obtainAuthorizationHeaderForScope without the logged out realm Realm2.
In JavaScript the equivalent call is:
WLAuthorizationManager.obtainAuthorizationHeader("SomeRealm")