I want to create a simple login module which authenticates users so they can, through a servlet using the weblogic client, access EJB's methods annotated with #RolesAllowed. As you probably noted, I have two seperate tiers - one with a webapp (Tomcat) and one containing business logic (WebLogic).
Generally speaking, I followed this JAAS tutorial (setting things accordingly).
According to the answer to this question, the principals should be propaged to the business tier (even having the tiers on separate machines?)
However, what I'm getting is an error page with following header: HTTP Status 500 - [EJB:010160]Security violation: User <anonymous> has insufficient permission to access EJB type=<ejb>
Also, I created corresponding roles in the WebLogic console.
Some tests from the servlet's GET method (without calling Bean's annotaed method):
request.getUserPrincipal().getName(): ADMIN
request.getParameter("role"): null
request.isUserInRole("admins"): true
(request is obtained from the argument #Context HttpServletRequest request)
Is there any additional thing to do to make it work? Or is it sufficient but there may be an error somewhere?
Let me also point I'm quite new in creating Java EE applications.
Help appreciated
The integration of security information between a servlet container and an EJB container is vendor specific. The question that you cited refers to remote calls between containers from the same vendor.
In your case, you have two different vendors - Apache Tomcat and Oracle WebLogic. Therefore, you are going to have more work to do.
You don't state which version of WebLogic that you're using, however the article Using JAAS Authentication in Java Clients describes the additional steps that you need to do in order to correctly propogate the security context from Tomcat to WebLogic 11g. You will likely be able to find similar information for other WebLogic versions.
Related
Windows Server 2012 R2, IIS 8
I did some more diagnostics. What is it about this line in the web.config file which overrides the Authentication configuration specified in IIS?
<configuration>
<system.webServer>
<modules>
<add name="Webhook" type="MyApp.Webhook" preCondition="" />
</modules>
</system.webServer>
</configuration>
I copied my Webhook folder to a Webgate folder and mapped the Webgate site to the Webgate folder. Through trial and error I can see that as long as that module is defined in the web.config file, the site can be accessed anonymously. As soon as I remove that line, I see the 401 Unauthorized on an anonymous request. Strange, why should the specification of my module which handles request, override the IIS specification which stipulates that request must be authenticated before they can be executed?
Here is the original question with the background on what I've been trying to do and the problem I've been having:
I have a web application - Webgate - set up to Disallow Anonymous access. Here's what this looks like:
The problem is, when I use Postman to interact with this application without any Authentication, the transaction succeeds. Here's what this looks like:
How can this be?
One more screenshot to confirm that this is the application which answers to that URL:
Here is the one complexity, although I fail to see how this could have anything to do with the issue. Both Webgate and Webhook (see screenshot above) are two sites within IIS which are mapped to the same web application in the filesystem. Webgate is configured to insist on Authentication, Webhook is configured to allow Anonymous access. Again, I fail to see how Webhook's allowance of Anonymous access could have any impact on a transaction which comes in on the Webgate binding. Some background for context: Application capabilities when coming in via Webgate will be a superset of what is accessible via Webhook. Security can't be short-circuited by coming in on the wrong interface because transactions are checked at the application level to confirm whether the current transaction is identified or anonymous. The whole purpose of the two sites is so that accesses via the open interface - Webhook - are never challenged for identity, whereas transactions coming in on the protected interface - Webgate - are always challenged for Authentication.
I've done this before, although not recently, and I've never run into this problem. There is that little complexity, but bottom line, if a site is set up to disallow Anonymous access and insist on Basic Authentication, how are transactions getting through without being challenged? That is something I have never seen before. Thank you for your advice.
The Issue Revisited
To summarize what we learned so far,
You wrote a managed module for ASP.NET.
This module hooks to pipeline event OnBeginRequest to perform some business logic and calls ctx.ApplicationInstance.CompleteRequest() when finishing.
Anonymous authentication was used on IIS side.
Everything works fine there, but you found that,
When Basic authentication is used on IIS side things started to break in integrated pipeline mode
Switching back to classic mode seems to solve it.
The Cause
Your module works in classic mode no matter what authentication method is used, because the whole ASP.NET pipeline runs behind IIS authentication module.
However, integrated mode works differently from classic mode, where your module no longer executes behind authentication but ahead of.
You confirmed that by collecting FRT.
The Solution
Like we discussed, the solution is to simply change your module so that it hooks to OnPostAuthenticateRequest instead.
References
Microsoft published the pipeline changes in an important article, so everyone should get familiar with the details.
Migrating from classic to integrated requires a good guide
FRT is always a handy helper for module/handler developers
I have a Spring-boot web application that uses Apache Shiro for security management. The web application also uses the Atmosphere framework for socket communication.
Whilst working with it I have a requirement to authenticate a user who is currently logged in when I receive /socket request to atmosphere. However, when trying to access the Shiro Subject I get the following error:
No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration.
I also have a filter added to my SecurityManager for /socket. Regardless, I continue to get the above error when I try to authenticate the user with atmosphere for socket connections.
I have searched up quite a lot on the web and haven't found an answer that explains what's happening thoroughly. I found many posts that mentioned something about the thread pool used by atmosphere is different from that which is allocated to servlet requests. Thus, async requests that reach atmosphere have no context of the original user. I also read a workaround here, which is quite old. I tried some of the things mentioned in the comments too.
Note: I am a newbie to the Spring, Shiro and Atmosphere frameworks. I understand things in a more systems-level perspective.
I would highly appreciate if I can get some explanation (or some link that might help) as to what is happening with each of these things and why it is producing the error above. Most of the online material I have read regarding this seems to be very vague and does not cover as an exclusive answer.
If I am not mistaken when the Spring application launches it also loads the Shiro and Atmosphere, related classes. The requests arrive at the Apache server and are delegated to a class based on annotations. Spring/Apache stores per request info (some cookie or session token) and subsequent requests are mapped according to this. However, the information stored between requests that hit the Atmosphere related (ex: onRequest) endpoints and the rest are not shared, hence I cannot use the same subject info.
I have sincerely searched a lot trying to understand and would like an elaborate explanation. I hope this question is not regarded unsuitable to the forum.
Thank you
Shabir
Take a look at the doc for Thread Association in Shiro
Your assumption seems correct (guessing as I've never used Atmosphere). The thread pools are different. There are generally two ways to deal with this. Some frameworks allow you to add data to a "context" and you can pull that data out from your running thread (much like a Servlet or Spring context). The other option (assuming you have access to manage the Atmosphere threads), you can wrap them in:
Subject.execute(...)
I am using Cometd 3.0.1 with jetty 9.2.3 using JSR 356 based websocket implementation (and not jetty's own websocket implementation).
I have added some auth filters which basically ask for authentication headers from request. But as websocket upgrade happen as a part of websocketupgrade filter, is there a way to make authentication work here?
Authenticating via a Filter is the wrong way to accomplish authentication.
Correct Solution:
The servlet spec expects you to setup and configure the the authentication and authorization layers of your application using the servlet techniques of both the container and the application metadata (WEB-INF/web.xml)
This means you setup a the container side security, either using the Jetty container specific LoginService, or using a JAAS spec configuration. Then you reference your security realms in your WEB-INF/web.xml and use them. If you have something custom, then you can hook into the LoginService of your choice (even a custom one) and manage it accordingly.
JAAS and LoginService Authentication and Authorization is applied before all filters and servlets.
In this scenario, you'll have access to the authentication information during the upgrade process, in particular during the ServerEndpointConfig.Configurator.modifyHandshake()
Ugly Hack Solution:
Add the org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter to your WEB-INF/web.xml manually.
This then leaves it up to you to attempt to get your authentication filter to exist before this WebSocketUpgradeFilter in 100% of use cases.
Caution: filter execution ordering is not part of the servlet spec. Be careful with this, as it might seem to be working on your dev machine and then suddenly not work in QA or production. Simply because the Set of filters in the metadata will have a different order in it.
Notes:
Path Spec must be /*
Async Supported must be true
Dispatcher Types must be REQUEST only.
Do not set the contextAttributeKey for that filter
All other WebSocketUpgradeFilter init-params are invalid for JSR-356 use (they are overridden by the various JSR-356 endpoint configurations)
I want to know if I can use Apache Shiro to secure the business tier of an (container managed) Java EE application. I'm asking because I haven't found any examples but only statements like "it works in web, EJB, and IoC environments".
Apache Shiro, in comparison with the default Java role-based access control, seams to have more extensive ways to authorize users (e.g. permission strings), which I hope one can use as a replacement to secure the methods of session beans in an annotation based manner.
Is this possible and has anyone tried it? Are there restrictions? An example or tutorial would be nice, too.
Ok, I had overseen that answer from Les Hazlewood from 2010.
The essence is that support for securing EJBs is given, if the subject could be bound to the current thread. This happens automatically through the Shiro Filter if the request is initiated from a web environment.
He further states:
Once the Subject is associated with a thread, AOP is one of easiest
ways of enforcing security restrictions. Then you can annotate your
EJB methods [...].
You can use the shiro API as simple java code in ejb.
You can use https://issues.apache.org/jira/browse/SHIRO-337 too
I am going to run a Web App on JBoss App Server 7. Does JBoss have some sort of inbuilt user management module/API which I can use rather than code my own? Or do I have to make this module myself. I know about the default JAAS pieces providing authentication AND authorisation, however I am looking to manage, add, edit, delete users from the datasource as well.
I'm not being lazy or anything, just want to know if JBoss has an easy inbuilt way before I start :)
Google implies no so I want to make sure by asking here.
As far as I know they don't provide any easy to managed identity provider, they "only" provide way to connect to identity provider using standard protocol like LDAP, SAML and WS-trust, openid to provide container managed authentication.
They have a idm project but it seems to provide standard protocol SSO identity backed by some identity store but doesn't provide way to manage the users.
PicketBox and PricketLink are the tow JBoss project you should look for more information.
These element can be used if you want to use global identity system, existing one, new product deployment or custom build.
(disclaimer: I have sped some time on Picket* projects documentation and I still don't think I get a good knowledge on how it works... )
There is a web interface and a command line interface for management operations. See the Management Clients section of the documentation.
The security realms could be what you're after. I'm not really a security expert though.
Maybe a security domain could be helpful too.