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).
Related
I have an xAPI content made by storyline I want for the statement to be sent to a webapp instead of the LRS.
this webapp is developped using laravel, and user should be authenticated with email and password to use it.
what I did to send the statement to this app:
1.in the webapp I created an API endpoint route that use POST method.
2.in the xAPI wrapper I changed the endpoint in the configuration to the route I made in the webapp.
const conf = {
"endpoint":"here I added my api endpoint route of the webapp",
"auth":"Basic " + toBase64(""),
}
now whith any interaction with the content where a statement should be sent the request making cors error like in the picture down, I think this is authentication error, how can I add my authentication credentials to the xAPI wrapper?
Your non-LRS LRS is probably not handling preflight requests which are necessary for CORS handling. Most common LRSs will handle those requests appropriately since they expect to be accessed from additional origins. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests
Also note that you'll likely run into issues unless you also handle state requests.
Additionally unless you are requesting the credentials from the user during runtime then hard coding the credentials into the package isn't a great idea from a security perspective.
In my Grails 3.2.9 web-app I'm using Spring Security plugin to manage user session. This is the depencency:
compile "org.grails.plugins:spring-security-core:3.1.1"
The natural (years-long) evolution of the app brought to have basically all actions in all controllers, mostly secured using #Secured annotations, to return a JSON, with something like
return map as JSON // grails.converters.JSON
That means that all actions are basically acting like APIs.
But since they're secured, when user is not logged, a redirect is performed to /login/auth (login page), which is something you wouldn't expect. This is why I'm searching for a way to return 401 unauthorized status instead of letting Spring Security perform a redirect.
So far I've looked into pessimistic lockdown, and searches across the web also lead me to Spring Security Core REST plugin, but both ways don't seem to adapt to my case (to me at last, but maybe I'm missing something).
So any suggestion is welcome, thanks in advance!
Register the following in resources.groovy
authenticationEntryPoint(Http401AuthenticationEntryPoint, 'Bearer')
I do not have experience in Grails but perhaps what you are looking for can be implemented by providing a different implementation of org.springframework.security.web.AuthenticationEntryPoint in your Spring security configuration. By default for form authentication Spring uses org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint which performs redirect to the given login page. On the other hand org.springframework.security.web.authentication.HttpStatusEntryPoint just returns the desired status.
In our project entry point is set in the old fashioned way through XML configuration:
<http pattern="/**" auto-config="false" entry-point-ref="yourAuthenticationEntryPoint">
I have an MVC4 project with simplemembership configured. It's all working etc. but I would like to know how to tell it wich controller/action to redirect to when a user is not authorized to view a given page.
For example, if I use [Authorize(Roles="Admin")] and try to view that page with a logged in user that does not have the "Admin" role it redirects me to the login page, even though I am already logged in.
I would like to change this to something else... maybe a 404 or a nice message to say "You are not authorized to view that content".
I've tried googling for just about everything I can think of to do with this but haven't found an answer so far.
Can this be done with the current setup or do I need something else? A pointer in the right direction would be appreciated :)
Try creating a custom AuthrorizeAttribute and override the OnAuthorization method so that you do a redirect to your custom page if authorization fails and to the logon page if authentication fails. Another approach that some people use is to check if the current user is authenticated on the logon page and if they are you can assume they were redirected to this page because authorization failed. In that case display a special message to the user indicating that they are not authorized to access that page. For some applications this may make sense because a user might have multiple accounts and they want to logon to another account where they are authorized to perform the operation. Some of these concepts are discussed in this QA.
This is, unfortunately, a problem with Asp.net as a whole (although it originates from a problem in the HTTP specification), it does not differentiate between unauthorized users and unauthenticated users, even though they seem to go out of their way to talk about the difference. In order to change this behavior, you would have to write a lot of code, and it's just easier to write a custom handler to check if you are already authenticated.
The HTTP standard never intended for a user to be in an "authenticated state". In fact, it doesn't really even know about the concept of a "user". Each page request is intended to carry information independent of the other page requests. The fact that browsers cache this information (or authentication is done by cookie) is irrelevant to what the standard intended.
The standard basically says that the server should issue a 401 if the requested resource is not authorized, and since each request has it's own authorization, the intention a simple pass/fail scenario. There is no concept of an authorized state for the site. The request either succeeds or fails.
I think frameworks like ASP.NET have gone a long way to creating their own authorization/authentication state, but they really should just go all the way here.
You might find this thread enlightening regarding the disagreement among the web community about the exact interpretations.
403 Forbidden vs 401 Unauthorized HTTP responses
I am developing a REST API, and have found a very interesting problem.
When I access the resources in a web browser (in my case Chrome), everything works fine. However, when I access the resources using a REST client (Google Chrome plugin, web-based client, and a Java applet), NONE of the variables pass to the API. This happens both with GET and POST methods.
I have absolutely no idea why this would be the case, and it's proving very difficult to test the methods before putting them into production (especially with POST methods).
Please help!
At first glance it sounds it could be 2 things:
You are not correctly passing API parameters via your client or
applet
A problem with authentication or cookie management. Does the API require any type of authorization?
Are you forgetting to set a necessary HTTP header?
Do you have control of the API also or is it a third party API? If so, do the params arrive at all or do they arrive empty? What's the error code? - a 403 not authorized (which would make sense if the key doesn't pass) or something else due to missing params.
Try the intermediate step of doing it with CURL form the command line - that'll give you more detail on what's coming back.
We are currently facing a production issue on Websphere 7 with respect to richfaces fileupload component. The problem description is that immediately after the file for upload is browsed and selected using this component, the basic authentication dialogbox appears asking for user credentials.
Following are the frameworks we are using in our project:
JSF 1.2 & Richfaces 3.3.3
Spring Framework 3.x
Spring Webflow 2.1
Spring Security 3.x (only basic authentication using login dialogbox)
The user is authenticated once when he wants to access the application at the beginning using basic authentication. All screens that dont use fileupload component are working fine. But if we use fileupload component, as I mentioned above, the file selection (even from local machine path) triggers the basic authentication dialogbox again. The strange thing is that this behaviour does not occur on our Dev Environment which uses Tomcat 6. On Tomcat, the fileupload is not triggering any user login and upload is working fine.
This problem is occuring only when the app. is deployed on Websphere 7. Can anybody please tell whether Websphere requires any additional configuration for accessing Files through this component ?
We have spent a lot of time investigating this problem without any meaningful results. As this is a production issue for us now, it is very critical and needs to be resolved at the earliest.
So please help in this regard. Thanks in advance.
I don't know the File Upload component, and the answer may well lie in the detail of how that works, but in general WebSphere will challenge if an HTTP request arrives for a protected resource and the request does not contain a valid LTPA cookie. The cookie is normally sent by the browser on each request when authentication has happended once, BUT it will only do so if it believes that the cookie is related to a given domain. So if the main part of your website were served from, say,
htpp://my.own.org.com/mysite
and the file upload were related to a subtly different host
http://my.other/filesite
Then the cookie would not be sent, and a challenge would result.
My approach to diagnosing this would be get some kind of traffic sniffer. See exactly what is flowing and the addresses being used. I'm predicting that you will see the LTPA cookie in the usual case and not in the upload case. Then it's a matter of figuring out "why".