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)
Related
How to force implementation url to listen from proxy only in Mulesoft?
Right now proxy can be secured using client_id, client_secret etc. However implementation url is not secure. By chance if anyone knows the implementation url then its potential risky affair.
Is there any way we can force implementation url to listen to proxy only.
(or) Can we add policies to Implementation url.
Mulesoft documentation setting-up-an-api-proxy states that the proxy application is nothing but a mule application mocking the contractual behavior of the actual service implementation and making service calls to the actual API for fulfilling requests. So instead of HTTP, it is recommended to use HTTPS for enhanced security and data integrity. Since Mulesoft suggests using HTTPS protocol for the connection between mule proxy and service implementation, so leveraging the HTTPS protocol, one option would be to try enforcing two way SSL between your proxy and the implementation which will help you accept requests only from legitimate clients.
Check the topic enable-two-way-ssl-in-mule for further implementation details
The second option would be to enable policies on the actual service implementation i.e. enable api-auto-discovery on your service.
Although you can do it but it would be an overhead due to below reasons :
As you would be enforcing policies at two layers and doubling the
calls to API Manager for sync up of policies as the service
implementation would poll the API manager every fixed interval of
time to check/fetch the policies.
To enable the policy application on the service implementation, the
service needs to run on either api-gateway runtime or mule 3.8
onwards runtime as older mule versions do not support policies.
The implementation can be done by having below XML snippet in the API xml.
<api-platform-gw:api apiName="app-${env}" version="${api.version}" flowRef="api-main" create="true" apikitRef="api-config" doc:name="API Autodiscovery" />
apiName would be the API definition created in API Manager from where
you can view and manage the API
version would be same major version of the API
flowRef would map it to the main flow reference
create flag to signify if the definition needs to be created in API Manager in case it does not exist
Conclusion:
Enforce 2 way SSL to enforce client-server certificate based authentication
Add Auto Discovery to service implementation so to apply policies on implementation layer as well
Mulesoft documentation suggests adding VPC . When we tested http was working in VPC but not https.
Since https was a mandatory requirement and we were unable to do it via VPC , we fixed it in a different way.
We added a custom header at proxy code and we validate for that header in implementation .
This was the fix rolled out
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.
I am planning to use WSO2 Identity Server as an Oauth2 provider. However the authentication is to be provided by my enterprise service which uses SOAP Protocol.
Basically I have to send a username/password combination to my service and it provides an authentication response. I understand that I need to implement a custom authenticator but I am not sure how to plug into ws02 IS, having read some of the custom auth docs. The questions are the following
Should I implement a LocalApplicationAuthenticator or FederatedApplicationHandler ?
I understand there is a method called canHandle() in AuthenticationHandler but not sure what to write in my scenario.
What are the various configurations that I need to apply to make custom authentication handler work?
Can I build my custom authentication handler as a normal jar file since I am not comfortable building OSGI bundles?
Thanks
I'd suggest to implement a custom user store, see:
http://pushpalankajaya.blogspot.be/2013/09/how-to-write-custom-user-store-manager.html
there is a method 'doAuthenticate' you may implement as you see fit.
Have fun
g.
We are planning to have multiple client views/UIs (E.g. Customer facing UI and Internal UI) on one (same) set of web services which perform end-to-end operation needed for both views/UIs including login. I am assuming this is possible with minor modifications to the out of the box code generated by Jhipster. Mainly around ..
- enabling CSRF
- changing WebConfigurator, ???
- decoupling web services from UI into separate wars/apps
- pointing to the new web services url in the client side
- ???
I would like to know experts opinion on achieving the same, and kind of changes and effort involved.
CSRF will work with JHipster 2, be careful as currently Spring Security and AngularJS don't use the same CSRF cookie (and thus, don't work!)
I would limit the URL access, maybe by IP adress, either in the Spring Security configuration or per endpoint (by adding security annotations per endpoint)
I need some help with securing a single page multi-tenant saas application.
Questions:
1) What is the best way to implement it? I am trying the build the application using angularjs, spring mvc and REST.
2) Can this be done using Spring Security? Any example with creating login page and securing REST, calls will be helpful?
I have found a sample for implementing spring security with Spring JPA (http://krams915.blogspot.com/2012/01/spring-security-31-implement_3065.html) but it is not for SPA and SaaS.
I understand this a very broad question but i am new to SPA, REST and SaaS so any pointers will be helpful.
Thanks...
I have already participated in two projects with SPA and security aspects. Last of them was GWT + Spring Security. I am sure that you can use successfully Angular and Spring Security together.
Unfortunately there is no built-in config parameter 'we are in SPA mode' in Spring Security AFAIK. So some tweaking / conf from Spring Security side will be necessary. Example:
imagine that during login you call built-in into Spring Security login controller. In a case of successfull authentication by default user will be redirected to index page, where in a case of failure it will be redirected to corresponding error page. It is a normal behavior for standard web applications that will be not so useful for SPA web applications. In a case of SPA you need to detect AJAX call and print JSON with username / roles for successfull cases or send 401 code for failures (then detect 401 in JS and show corresponding error). You can use corresponding extention points from Spring Security to do so: AuthenticationSuccessHandler and AuthenticationFailureHandler.
Some another thing to tweak: by default after session expiration user will be redirected to login page (and SPA app receive login page as a response to the next AJAX call).
Looking into my personal exprience general guide will be like so: after login load list of roles into JS. Use it to show / hide corresponding components on UI side. Apply the same list of restrictions on server side too. To make sure that user do not edit JS in browser (although in a case of minified JS of some medium size app it will very complex task). On the server side you must choose between:
Secure URLs of AJAX calls
Secure some Java methods.
I prefer second one (secure business methods on services). I think it is more convinient because normally we want secure business operations, not some endpoints. As adwantage you will be able expose your business logic via some other protocol, and security will be there already. From other side I can imagine some business requirement to have different permissions for different endpoints / protocols. So it depends more on your actual situation.
Lage size JS applications must be splitted into modules. To decrease direct dependencies it may be better to use events insted of direct calls to cummunicate between modules. There are interesting thoughts of Addy Osmany about how to do security in these coditions. I did not found good link to it, maybe this or this will be helpfull (search "permission").
Feel free to post any questions. Good luck.