I didnt find anything according this issue.
Can jaas be used to secure my rest service? When yes, are there any advantages compared to basic/digest auth + ssl? Should I use jaas over basic/digest auth for my rest service?
Yes you can use JAAS to secure a REST (or any other type of) service.... as long as your REST container provides the ability to hook JAAS Login Modules.
Most containers I know, do, Tomcat and Jetty in particular.
JAAS is no so much about how the credentials are formatted or made available (Form Login, Basic auth, etc...) but more about how you validate them. You may want to check a local file, query an DB or an LDAP server...
JAAS is not only authentication, but authorization too. Once you have passed the authentication phase, the roles and permissions you provide to the user. All containers that implement JAAS will provide a seamless integration between the JAAS module and the authorization scheme provided by the container such as the one provided by web.xml for servlets.
Since JAAS is a standard and is now part of the JRE, you will find a lot of ready-made modules and documentation on the web to help you build your own if need be.
Related
I would like to use javaee security, but I need to authenticate users against an external proprietary authentication mechanism, which is different from LDAP and any other standard mechanisms coming with Wildfly. In particular, I would prefer if the authentication is taken care of by the application, not by the container. I only have come across PolicyConfiguration. But I think that it implies buiding an extension to be plugged into the underlying application server.
What I would like is to let application server obtain credentials in a standard javaee way, then execute a callback into the application in order to authorize them, and then establish current user together with his roles, so that I may use declarative security using annotations.
Is this possible in standard way? Or the only solution is to build an extension module for the application server?
An not so elegant solution would be to perform the login using HttpServlet.login. You still need to configure a realm that would acknowledge the username and password you provide in the method call.
Another, more complex, solution would be to create an JASPIC authentication provider. In short, you are in charge of the whole authentication process. Here is a collection of resources to get you started: Zeef
I was trying to register an Application Login Module in Websphere but I don´t find any easy example in web.
There are a lot of IBM documents, but too much complex, and I can´t figure out how to register an Application Login Module.
I already have success with a System Login Module bounded to WEB_INBOUND, it works, but affects all my system. I want a Login Module to serve only my applications web, with JAAS authentication.
I´ve tried to bound a login module to existing WSLogin but it doesn´t seems to be working.
Any help ?
tks[]
You need to setup security domains to get the separation you are looking for wrt to the login configurations. The security framework uses the WEB_INBOUND login configuration to authenticate the user for all web applications irrespective of adminConsole or user applications. When you create a security domain and customize the WEB_INBOUND configuration at the server/cluster domain level, it will be used for all the user web applications deployed in those processes. You need to setup the multidomain in a cell topology and assign the domain to the server/cluster where you applications are deployed.
Once you setup the domains, the WEB_INBOUND configuration at the server/cluster domain will be used by the user applications hosted in that server/cluster while the WEB_INBOUND configuration at the admin/global domain will be used for the adminConsole application at the Deploymener Management process where it is deployed.
The application JAAS login configurations are meant to be used by the applications directly. One can create an application login configuration and programmatically use it in the application to perform direct login -
LoginContext lc = new LoginContext("myAppLoginCfg1", callBackHandler);
I asked around and this is the answer that comes from the owner of container security:
The WEB_INBOUND is a JAAS system login that is always configured by default. However, you can specify your own JAAS application login or customize the existing WEB_INBOUND system login. If you want only one application to use a different JAAS login from all your other applications, you can use a security domain that has those different security configurations. The only catch is that application server has to be in a separate server from the other apps. That way, you can map your security domain to that server.
Here's an info center article about security domains:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/tsec_sec_domains_config.html?cp=SS7K4U_8.5.5%2F1-8-2-33-1
And one on application logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/rsec_logmod.html?cp=SS7K4U_8.5.5
And system logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/usec_sysjaas.html
And here is a much more practical answer that comes from the security dev lead:
So an additional question is - why would you want to do that? Do you want to do anything specific for just one app during login that you do not want for other app logins? (I would think so) You can get the app name in your custom login module and can use that to provide your own app based login requirement in your login module (or skip it) if needed.
Me: Ya, this is what I would do. You can also implement this based on what is in the request. I did one where it would request a SAML token from an STS and put it on the runas subject if I could tell that the request came from WebSeal (and not if it didn't).
If what you need to do for the 'app-specific' case requires skipping what is done in ltpaLoginModule and wsMapDefaultInboundLoginModule (that should run for the other apps), you can't really do that. However, you can modify their behavior.
Read through the task I've given a link to below. Yes, I understand it is a WS-Security task, but its about using APIs. You'll get what I'm talking about if you read closely, particularly the 3rd ("When a caller...") and 5th ("To use a..") paragraphs. The parts that you should be concerned about in the code is the WSCREDENTIAL* stuff.
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_config_wssec_caller_no_reg.html
Can I use spring-security-rest as a replacement of Oauth?. My app has server side part and java script client side part where I found that spring-security-rest plugin fits most. But I want to be able to authenticate other apps who want to consume my service (I want to be something like Oauth provider). Does spring-security-rest plugin support this? or should I use another plugin?
The plugin is not a fully OAuth provider. Or said in OAuth terminology, is not a full Authorisation Server.
In that case I recommend you Spring Security OAuth 2 Provider Plugin
If you are looking only for a simplistic token based authentication for your service, you could leverage the spring security rest plugin and tweak it a little bit based on your need without having to implement the full blown Spring Security OAuth2 Provider plugin. I managed to accomplish something similar with by extending some of the base classes of spring security rest plugin to modify the login payload and authentication and exposed a token/validate as a REST endpoint. I put up this as an independent authentication service that uses the /api/login API for token generation in tandem with the /token/validate to accomplish some kind of validation on token. Not a full blown Oauth scenario but serves the purpose of authentication between consumer and provider services.
Our current app is a standard spring 2.5 application with Form Based Authentication using Acegi. However, we need to expose some REST Service for 3rd party application and we are trying to use BASIC auth over SSL. We have used RESTEAsy for exposing the REST Services. Now, given that the rest of the application uses form & Session based authentication, how can I enable basic authentication for the few REST Services.
To me, the usecase seems normal, however, I couldn't find much reference on the web. Any comment/suggestions will be very much appreciated.
Regarding the more general question of whether to secure the REST service using Form authentication or Basic/Digest authentication - this is deeply tied into one of the more important constraints of RESTful architecture - statelessness.
With this in mind, logging into a service means keeping state on the server, which goes against the stateless server constraint. From an authentication POV, Form based authentication implies logging in, whereas Basic/Digest authentication means embedding the authentication credentials in each request, with no need to keep any state on the server. This is why this kind of authentication is much more inline with the way REST is meant to be build.
Hope this helps.
Check out Basic/Digest Authentication in the Spring Security Reference.
Are there any open source centralized authorization services available? There are lots of solutions for centralizing the authentication information (eg: CAS and JOSSO), but what about the authorization information?
There are some really good authorization frameworks (eg: Spring Security (formerly Acegi) and Seam Security), but it seems that I have to composite these into individual tiers or services. In other words, I can't run them standalone very easily. With a SOA, it seems like it would be very valuable to centralize not just the authentication but the authorization information as well (ie: roles, permissions, rules, etc.).
Any suggestions?
Are you looking for something that supports XACML? If so, the closest to open source you can get is the OpenSSO project which has portions of what you seek.
The openly available Kerberos implementations provide Client Service Authorization as well as Client Authentication.
Read about Using Kerberos 5 on Red Hat Linux.
Hum, maybe you can use a SSO solution and create a service which returns all the authorization information (roles, permissions, rules, etc) and make each application use this service to get each authenticated user authorization information.