dlitvak

I don't believe external auth has changed in 6.3 or 6.4.x 6.4.2 is the latest Jasperserver version, not 6.4.3

It's not so bad as sessions expire. You can set the following properties in <bean id="proxyPreAuthenticatedProcessingFilter" class="com.jaspersoft.jasperserver.api.security.externalAuth.preauth.BasePreAuthenticatedProcessingFilter">[/code]<property name="checkForPrincipalChanges" value="true"/><property name="invalidateSessionOnPrincipalChange" value="true"/> These properties are coming from Spring class of which the bean class is a subclass.

Any errors?

There should be no difference between ce and pro in pwd encryption.

What link did you follow? Were there any javascript errors? F12 -> Console in Chrome What about log errors in jasperserver.log?

Note that unless you specifically use external authentication to authenticate users via rest or webservices, proxyBasicProcessingFilter can me completely removed from the sample file. As a result of this, delegatingPreAuthenticatedFilter in applicationContext-security-web.xml will fall back on the non-external basicProcessingFilter behaviour. Sample file is provided just as that. It includes more scenarios than you might need.

It is fixed in 5.6 according to defect 35935 records that I filed.

Please post jasper logs at debug level, version of the server, customization details, etc.

This is going to be fixed in 5.6 release. 5.6 has been scheduled for April.

sorry, d{5,} should not work as the encrypted passwords are hex. It's a bug anyways.

James, It's a definite bug which was introduced in 5.1. I opened an issue and linked it to the original bug, which I re-opened. So far, the engineer works to make it fixed in 5.6. Sorry for any inconvenience. Dmitriy

Sounds like a bug, logging it.

Try with a simpler regex first to see if it works. ^d{5,}$ for example. Most likely it won't, but still. Have you enable some js password encryption? encryption.on=true in security-config.properties?

Could you please post a stack trace? Some config excerpts could be helpful too.

Please note that password hashing has been broken. The part that is broken hashing-wise is user creation and user reading from db. We plan to fix it in 5.6 or 6.0. Sha-1/MD5 are deprecated for password encryption. They are considered as broken. Please use SHA-2 or better. I have only heard of other possibilities like scrypt, bcrypt.

Try userDnPatterns in ldapAuthenticationProvider's BindAuthenticator. This might help http://community.jaspersoft.com/documentation/jasperreports-server-authentication-cookbook/specifying-userdnpatterns-parameters <bean id="ldapAuthenticationProvider" class="org.springframework.security.providers.ldap.LdapAuthenticationProvider"> <constructor-arg> <bean class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator"> <constructor-arg><ref local="ldapContextSource"/></constructor-arg> <property name="userDnPatterns"> <list> <value>CN={0},OU=Users,DC=mycompany,DC=com</value> <value>CN={0},OU=Staff,DC=mycompany,DC=com</value> </list> </property> </bean> </constructor-arg> ....... </bean> [/code]If that is not enough, configure several ldapAuthenticationProvider's pointing to different branches. <bean id="ldapAuthenticationManager" class="org.springframework.security.providers.ProviderManager"> <property name="providers"> <list> <ref local="ldapAuthenticationProvider1"/> <ref local="ldapAuthenticationProvider2"/> .... <ref local="ldapAuthenticationProviderN"/> <ref bean="${bean.daoAuthenticationProvider}"/> </list> </property> </bean>[/code]Each ldapAuthenticationProvider can point to the its own userSearch1...N

If you plan an update of JRS in the future, it will be painful to remember to update the bean every time. Here is what you can try: Create your own applicationContext-rusty.xml <?xml version="1.0" encoding="UTF-8"?> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> /login.html?orgId=RustyRoss .... Other bean overrides for login.html .... Drop this into the deployment after every install.

Sorry, the subscribe feature has not notified me about your question. I would change login.html in applicationContext-security-web.xml. Everywhere you find it, add orgId parameter.

FYI, the internal bug number is 35242. The fix should be in the next release Spring, 2014

Actually, passwordExpirationInDays=0 and allowUserPasswordChange=false seem to be the defaults. What you can do is set allowUserPasswordChange=true. passwordExpirationInDays at 0 simply means that the password would never expire. Not very sure how I can keep you posted as our bug db is not public facing. I will talk to someone here.

Ok, I will log a defect on our side. Can you work around the issue for now?

Can I have you verify if allowUserPasswordChange is false in jasperserver-servlet.xml? If not, could you please set it to false and report what you see. I will try to reproduce the same issue on my side. The more I look at it, the more it looks like a bug.

After auth happens, what organization do you see the external user TESTLDAPUSER created under? Should be organization_1. What case does the username have in the database and what username is entered in login form? TESTLDAPUSER? It could be case sensitive depending on configuration. isUsernameCaseSensitive property of UserAuthorityServiceImpl bean is false by default. Please describe what exact steps you perform to authenticate the user. Any unusual configs? A thing to try would be to add orgId=organization_1 parameter to the login.html url. Please report your findings here. This might be a bug that we need to address. Thank you!

One more thing. For your case, I would reccommend using userDnPatterns BindAuthenticator property instead of userSearch. Please refer to Spring Security LDAP reference guide.

Matt, It looks like groupSearchFilter propery in DefaultLdapAuthoritiesPopulator is also missing &. If adding that does not resolve authentication issue,I recommend dropping DefaultLdapAuthoritiesPopulator property altogether until you can login. DefaultLdapAuthoritiesPopulator is responsible for extracting user roles. If you remove it, the authenticated users will be roleless. But this is fine since JasperServer assigns a default ROLE_USER.