JAAS LoginModule flags - jaas

I'm trying to work out how the Login module flags work in JAAS (using JBoss 5.1 EAP) and I've come across a puzzling situation that I'm hoping someone can clarify for me.
For background, my login-config.xml looks like this:
<authentication-policy>
<authentication>
<login-module code="...loginModule1" flag="sufficient">
...
</login-module>
<login-module code="...loginModule2" flag="optional">
...
</login-module>
<login-module code="...loginModule3" flag="optional">
...
</login-module>
</authentication>
</authentication-policy>
In this case, loginModule1 is standalone, but loginModule2 depends on loginModule3. The problem I've got is that if loginModule1 fails and loginModule2 and loginModule3 both succeed I still get a failed login. If I change loginModule1 to be optional then when loginModule1 fails and 2 and 3 succeed I get a successful login.
From the JBoss security documentation (http://docs.jboss.org/jbossas/admindevel326/html/ch8.chapter.html):
sufficient: the LoginModule is not required to succeed. If it does succeed,
control immediately returns to the application (authentication does not proceed
down the LoginModule list). If it fails, authentication continues down the
LoginModule list.
I would have thought based on on this that when LoginModule with a sufficient flag fails, but a following LoginModule passes then I would get a successful login, anyone know why this isn't the case?

You should check out the java documentation on the javax.security.auth.login.Configuration class, it has all the information on what sufficient, required, requisite, and optional mean. What is pertinent to your question is this paragraph:
The overall authentication succeeds only if all Required and Requisite LoginModules succeed. If a Sufficient LoginModule is configured and succeeds, then only the Required and Requisite LoginModules prior to that Sufficient LoginModule need to have succeeded for the overall authentication to succeed. If no Required or Requisite LoginModules are configured for an application, then at least one Sufficient or Optional LoginModule must succeed.
This is what should happen, so it seems like your setup is correct, but something is not returning correctly so everything is failing. Maybe JBoss does something a little bit differently.

Related

How to map LDAP Usergroups to Wildfly roles

we have javaee application running on wildfly 18. authentication is done by kerberos security-domain (com.sun.security.auth.module.Krb5LoginModule). this works just fine.
now we need to know, whether authenticated user belongs to certain usergroup in LDAP.
any idea how to do that? i assume we need to configure LDAP connection and then somehow map LDAP usergroups to wildfly roles, but i have clue where to start.
for any help or direction thank you very much.
I had similar problem like you.
In my case I first needed to migrate from legacy security to elyctron. In elyctron loading users and groups is first step, and then you have opportunity to map roles to whatever you want using role-mappers.
<security-domain name="ApplicationDomain" default-realm="ApplicationRealm" permission-mapper="default-permission-mapper">
<realm name="ApplicationRealm" role-decoder="groups-to-roles" role-mapper="KeepMappedRoleMapper"/>
<realm name="local"/>
</security-domain>
...
<mapped-role-mapper name="KeepMappedRoleMapper" keep-mapped="false" keep-non-mapped="false">
<role-mapping from="SOURCE_GROUP" to="TARGET_GROUP"/>
</mapped-role-mapper>

WSO2 API Manager - "Make this the default version" causes authentication errors?

I have an API that works no problem providing the "Make this the default version" checkbox isnt checked, once checked I get this error back
<ams:fault
xmlns:ams="http://wso2.org/apimanager/security">
<ams:code>900906</ams:code>
<ams:message>No matching resource found in the API for the given request</ams:message>
<ams:description>Access failure for API: xxxx/xxxx, version: v0.1 with key: xxxxxx</ams:description>
</ams:fault>
Is there something I have missed at all?
Thanks,
Ash.
EDIT - Extra Detail and Logs
TID[-1234] [AM] [2014-07-10 13:05:56,238] ERROR
{org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler}
- API authentication failure org.wso2.carbon.apimgt.gateway.handlers.security.oauth.OAuthAuthenticator.authenticate(OAuthAuthenticator.java:157)
org.wso2.carbon.apimgt.gateway.handlers.security.APIAuthenticationHandler.handleRequest(APIAuthenticationHandler.java:92)
org.apache.synapse.rest.API.process(API.java:285)
org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:83)
org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:64)
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83)
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344)
org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:168)
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
java.lang.Thread.run(Thread.java:744)
Please save and publish the API once you made the change to the API. This may be causing the issue.
Once you have published you should see 2 sets of production url (one with the version and one without the version). Please check if the same is available in the API store for your API.
You'll first want to turn on wire logs in that environment by editing your ../repository/conf/log4j.properties file and restarting the service. This will allow you to see the request headers for both the initial request to the gateway and the request from the gateway to itself (or other gateways in your cluster) since that's how requests to a default API version are resolved. This can help you identify whether your Authorization header values are actually making it to the authentication handler.
After you take a look at this, note that when you publish an API with a default version, you're actually creating (or updating) two separate synapse configurations for the API: a versioned configuration and an unversioned configuration. The portion of the latter's definition that you need to check is:
<else>
<header name="WSO2_AM_API_DEFAULT_VERSION" scope="transport" value="true"/>
<property name="uri.var.portnum" expression="get-property('https.nio.port')"/>
<send>
<endpoint>
<http uri-template="https://localhost:{uri.var.portnum}/myApi/v1">
<timeout>
<duration>60000</duration>
<responseAction>fault</responseAction>
</timeout>
</http>
</endpoint>
</send>
</else>
By default, the newly generated definition for the default version attempts to send the request to localhost, which may not be what you want. Check at ../repository/deployment/synapse-configs/default/api and make sure that this definition is correct.
Since it looks like this is actually an authentication error, you should also test a new subscription. Create a new application with some subscriber, subscribe to the API, and generate new access tokens. I wouldn't understand why (since setting a default version doesn't create a new API entry in the AM_API table) but this could possibly be due to the access token credentials being invalid for the default version, and generating new tokens should (in theory) test against this.

How to integrate CAS authentification in SonarQube

we want to integrate CAS authentication into Sonar 3.7 LTS. We want to start working with the deprecated CAS plugin, which of course doesn't work. We already compared it with the LDAP plugin from here whose Authenticator interestingly implements the deprecated interface LoginPasswordAuthenticator. One of the main differences is that the CAS Authenticator plugin implements Authenticator. So we altered the CAS Plugin that it implements LoginPasswordAuthenticator instead.
Now comes the clue:
In both cases, the authenticator implementing Authenticator or LoginPasswordAuthenticator, the username passed to it is null. The authentication against the CAS server works like a charm, the plugin knows the username, but Sonar asks the plugin, if it knows the user with the name null. The effect is that when we click on login we get redirected to CAS, fill in the login form and get redirected back to Sonar, still not authenticated to Sonar itself.
We also considered using container authentication but are not sure if that works with Sonar.
Now the question(s):
Has someone got the CAS plugin working with Sonar 3.7? If yes, how and can you provide the sources/solution/plugin?
Is there another way besides the suggested ones above?
One additional note: We want to use Sonar in our existing Tomcat 7, so using Sonar 4 is a way we do not really want to go because the Sonar team decided to stop war support. If anything else fails though, using it is a pain-in-the-ass-but-acceptable solution.
Thanks for your help.
Try this fork: https://github.com/jerzykrlk/sonar-cas.
I restored the behaviour of the original plugin - it should work with Sonar 3.7. It is unofficial at the moment, and will require a manual build. But maybe it will become an official plugin at some point, again.
Thanks to #psqita we got the CAS plugin for Sonar up and running with Saml 1.1. Business requirements said that no anonymous access shall be allowed. Sadly, setting forceAuthentication to true sent us into an endless loop of painful redirecting between CAS and Sonar. So we figured out that Sonar alters its behavior drastically in a way that it ignores all authentication plugins.
Our solution: As of business requirement we could not allow anonymous access. So we implemented another Filter that redirects conditionally to CAS. Authentication and stuff is still done by the plugin. Sadly, we still do not know why there was this endless loop in the first place but now it doesn't happen anymore. Well that's IT I think...
Thank you for your support and happy holidays.

Authenticate against EJB via RESTeasy webservice

I am trying to setup a REST-webservice with RESTeasy that access EJBs that are deployed on a JBoss 7.1.1.
I've been successful in:
Setting up Beans to be accessed via REST
Configuring SSL for the connection
Setting up a PreProcessInterceptor that uses HTTP Basic Auth to ask the User for his credentials.
Currently I basically just check the credentials hardcoded in the interceptor.
This works to make sure that the User is authenticated, but our Beans query for the name of the currently logged in Principal for some Beancalls like this:
#Resource
private SessionContext context = null;
[...]
String userName = context.getCallerPrincipal().getName();
Currently userName is now always anonymous. What is the right way to set the caller principal? Do I do this in an Interceptor? Or in the Bean itself? My goal is to basically be able to call a method loginUserWithEJBOnJboss(String user, String pass) that uses the login-methods that are configured within the jboss and sets the principal correctly.
I am at a loss here, google didn't find anything. Maybe I am just searching for the wrong words.
So yeah, as always soon after asking I find the solution myself. I think sometimes I only ask because I know this will happen.
So the solution are these methods:
SecurityContextAssociation.setPrincipal(new SimplePrincipal(username));
SecurityContextAssociation.setCredential(password.toCharArray());
They do pretty much all I wanted :)

Apache axis2 and Rampart not preventing 'replay attacks'

We use one of the older versions of apache axis2 for our web services framework. We are using rampart 1.2 as part of that.
Am trying to use password digest with ‘nonce’ and ‘timestamp’ mechanism for authentication. We’re getting rampart to do the verification.
I’ve got the authentication verification mechanism working fine (inc. password callbacks, etc.)
The issue I’m having concerns getting rampart to recognise a ‘replay attack’, basically the functionality of the rampart module associated with recognising these seems to be inactive.
I can send the same security header to my axis2 service any number of times (even sending a security header I generated yesterday) and it authenticates fine and completes the webservice request.
My best guess is : I’m missing a config setting somewhere for the rampart module that enables the functionality to detect replay attacks.
I’ve tried both the config suggestions given in the links below (in the services.xml file) and neither seem to work :-
http://hasini-gunasinghe.blogspot.com.au/2012_02_01_archive.html
http://axis.apache.org/axis2/c/rampart/docs/configurations.html (right at the bottom, it mentions ‘Replay attacks’)
Anyone able to help or give me some idea what I'm missing and where (I'd imagine it's config setting related) ?
I've got the module declaration for rampart in my axis2.xml file :-
<module ref="rampart"/>
And I have what I believe to be the rampart config settings in my services.xml file after all my operations are declared ;-
<parameter name="InflowSecurity">
<action>
<items>UsernameToken Timestamp</items>
<passwordCallbackClass>com.myCompany.service.dummy.MyAuthenticator</passwordCallbackClass>
</action>
</parameter>
<rampart:rampartconfig xmlns:rampart="http://ws.apache.org/rampart/policy">
<rampart:timestampprecisioninmilliseconds>true
</rampart:timestampprecisioninmilliseconds>
<rampart:timestampttl>300</rampart:timestampttl>
<rampart:timestampmaxskew>300</rampart:timestampmaxskew>
<rampart:timestampstrict>false</rampart:timestampstrict>
<rampart:ReplayDetection>1000</rampart:ReplayDetection>
</rampart:rampartconfig>
If you are using rampart-1.2 you will have to implement the replay detection in your service.
The incoming TimeStamp information is available in the Security header processing results included in the message context properties under the key "org.apache.ws.security.handler.WSHandlerConstants.RECV_RESULTS". This is a Vector, and the first item of this is a "org.apache.ws.security.handler.WSHandlerResult" instance (wsResult in the next code snippet).
Then you can obtain the timestamp information as shown below:
actionResult = WSSecurityUtil.fetchActionResult(wsResult,
WSConstants.TS);
if (actionResult != null) {
Timestamp timestamp = actionResult.getTimestamp();
//Your validation goes here...
}
As suggested by the blog post you referenced you can try upgrading to rampart-1.6.2 and using the policy based configuration.