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.
Related
I'm using CKAN with Apache and an SSO system called Cosign. Cosign works as an authenticator in Apache and ends up setting REMOTE_USER before the python code fires up. What I'm trying to do is use LDAP user lookup based on that preset REMOTE_USER. Can I do that with the CKAN ldap plugin (http://extensions.ckan.org/extension/ldap/)? Any advice greatly appreciated - I'm a Python and CKAN novice.
The short answer is that ckanext-ldap doesn't do that. What it does is provide a custom login form (username and password) that authenticates the credentials via LDAP. It then creates a session for the corresponding CKAN user, creating a user account first if required. Having it do anything else would require customisation of the extension although there are a number of options documented in its readme that alter the behaviour in small ways.
Whether ckanext-ldap would be a suitable extension to build upon to achieve what you want depends on what you want to do, which isn't clear from your question.
I'm writing my first Symfony app and and I need authenticate users over LDAP/AD, but I run out of documentation...
I found many solutions for use LdapClient, but it tagged as deprecated. So, i check for use the new one Ldap class as recommended, but I not found documentation for use it. The documentation of Ldap component for the current version (3.1) suggest to use LdapClient yet! It isn't updated yet?
I don't know how to do: must we create an adapter for add a Ldap service? If so, how to proceed?
Any help will be appreciated, thanks!
Check out this cookbook article for configuring LDAP authentication using the builtin Symfony component:
http://symfony.com/doc/current/cookbook/security/ldap.html
I also have a bundle I maintain that includes LDAP authentication that works well with AD called LdapToolsBundle. It has documentation on the main page for the app/config/config.yml entries needed to configure your domain for use in the bundle, and also some details on configuring authentication in app/config/security.yml here.
The bundle above provides a LDAP service called ldap_tools.ldap_manager that can be used to query/create/modify different types AD objects.
take a look at my Blog:
https://alvinbunk.wordpress.com/2016/03/25/symfony-ad-integration/
This requires FOSUserBundle and FR3DLdapBundle, but I think if you go through all that documentation you should be able to get LDAP/AD integration with Symfony3 working.
EDIT #2
Below is a second easier solution:
https://alvinbunk.wordpress.com/2017/09/07/symfony-ldap-component-ad-authentication/
After the user logs in with FORM authentication, I need to get the user's username. I'm using a custom login module that extends DatabaseServerLoginModule.
I'm runing JBoss EAP 6.2 (standalone) and Seam 2.3.1.
I've but a breakpoint in my loginmodule, and I can see from the stacktrace (and my browser's dev tools, where I can see the newly created JSESSIONID cookie) that the session has been created. I thought I could manually map JSESSIONIDs to usernames, but I can't see a way to find that. Inside my normal Seam Session scoped stuff, I could use FacesContext / ExternalContext.getSession(), but FacesContext.getCurrentInstance() is always null there.
In the stack trace I can see the FormAuthenticator and I thought I could get this stuff from there, but I haven't found a way to use a custom version of that.
I found something that recommended using an org.jboss.ejb3.annotation.SecurityDomain annotation along with a javax.annotation.Resource annotated / injected javax.ejb.SessionContext, but the SessionContext (from which I could call getCallerPrincipal) is always null. I guess Seam's idea of a Session and whatever that stuff maps to doesn't play well together.
I have a webpage in a Liferay 5.2.3 site, in order to view this page the user shoulde be logged in.
i tried JMeter for stress testing but i stopped after i had this issue here ("invalid authentication token"). What other tool i could use to do stress test without facing the authentication issue (with example of script if its available).
I had the same problem. I managed to log in and then when sending POST requests to the server I only received 403. What I have done is that I set the auth.token.check.enabled to false in the portal-ext.properties.
auth.token.check.enabled=false
But be careful. The Portal Authentication Token was implemented to prevent Cross Site Request forgery, as explained here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF).
On a production environment set the property back to true.
More about that on the liferay site: http://www.liferay.com/community/wiki/-/wiki/Main/Authentication+Token
Well I'm not sure but you could try Grinder, it supports jython as scripting language, although i dont have a working script example at the moment.
You can use JMeter but you have to use its proxy to record your actions (login included).
Please see JMeter proxy step by step
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".