Hi,
If you use the REST based code I posted, I might help. But I need to know the value of the different provider. SQL select * from ofProperty where name like ‘provider%’
Also the content of the crowd.properties file and the full stacktrace.
Hi Issa,
I tried to figure out how to compile your code but after sorting out the various dependencies i ended up getting this error (compiling against openfire 3.8.1):
CrowdGroupProvider.java:44: org.jivesoftware.openfire.crowd.CrowdGroupProvider is not abstract and does not override abstract method loadProperties(org.jivesoftware.openfire.group.Group) in org.jivesoftware.openfire.group.GroupProvider
public class CrowdGroupProvider implements GroupProvider {
^
CrowdGroupProvider.java:108: cannot find symbol
symbol : method getSharedGroupsNames()
location: class org.jivesoftware.openfire.group.Group
return Group.getSharedGroupsNames();
^
2 errors
It seems that v3.8.1 has introduced another method that needs to be implemented by the CrowdGroupProvider. Unfortunately it’s been way too long since i have last done anything in java so i can’t even help fix it…
Would be great to be able to keep uptodate with the openfire versions; despite using crowd as authenticator
Thanks,
Dennis
Hi Dennis,
Yes I know, I had updated my code locally, but haven’t tested it yet (we upgraded a lot of other tools at my work lately!)
I hope to be able to test it next week and report.
Maybe Openfire team can provide me with some space on their source infrastructure to manage it there, instead of here on the forum. (I know I declined the offer a while ago, but it seems more appropriate for every one)
–
Issa
Hi Issa,
You wish to have this be a part of the openfire source tree with commit permissions to update it there? I certainly would be in favour of this.
daryl
exactly that
Hi Issa,
I am willing to help out with this (as the developer who changed the Groups API for 3.8.1). I was unaware of the Crowd integration at the time, but would have included it with my changes if it had been part of the Openfire core (similar to the LDAP integration code).
Feel free to post your updated code here, and I will create a JIRA ticket to track the effort needed to integrate it into Openfire. We will definitely need some help testing the integrated code (I do not have access to a Crowd server), and potentially could use some updated user/admin documentation as well if possible.
Thanks,
Tom
Hi Tom,
I can help out with the testing, as long as i don’t have to compile stuff It took me quite a while to get everything in place yesterday (not having a dev setup etc.) so if we could find a way for me to get a jar or perhaps just some compiled code that needs to be dropped into an existing jar, I can reletively easily test it out.
Thanks,
Dennis
OK Dennis, sounds good. I have created OF-657 to track this request.
I did an initial inspection of the original RESTful implementation attached earlier to this thread. At a minimum we will need to replace the Jersey client-side stuff with something that is compatible with ASL 2.0. This will also remove an undesirable dependency on the private com.sun.* namespace.
Let’s wait and see where the current implementation stands (pending update from Issa) before putting together a plan of attack.
Okay, will take a look and see what can replace jersey appropriately… I hope there is something, because jersey was quite handy… Will put my comment in the jira issue from now on…
Hi Dennis, as you’re willing to test, please find the jar for the crowd-openfire providers.
You will need to have a crowd.properties file inside the folder conf of openfire described on https://confluence.atlassian.com/display/CROWD/The+crowd.properties+file
Also the three variables defined above (admin.authorizedGroups, crowd.groups.cache.ttl.seconds, crowd.users.cache.ttl.seconds)
Tom, please attach into issue in jira
OK - got it. Source attached to JIRA ticket pending review and merge into SVN. Thanks!
Thanks Issa,
See http://issues.igniterealtime.org/browse/OF-657 for more details…short of it is that i couldn’t get it to work
Much easier to setup though! only issue that other’s may also want to know about was that i was getting errors about the root certificate not being trusted for my domain. What i did was add “clearspace.certificate.verify=false” to my system properties (via the db) and it stopped complaining
Thanks,
Dennis
mvdkleijn
At our side, we have 5000 users and 13000 groups in Crowd. They are imported into Openfire and it works. Now, I must say that the console screens are not designed with such numbers in mind. But it works.
The negative point , at least for so many groups is that when you navigate in the console on users and groups, Openfire will retreive the memberships and there is some kind of recursivity that occurs. You end up waiting for all those REST calls to Crowd to complete to get your screen shown.
To mitigate those waiting times, I added caches, but they work only after the memberships are cached! And I deliberately decided not to fetch the memberships at Openfire startup because it would take too long (at least at our side).
I just switched from using AD authentication to using the Crowd connector to authenticate via JIRA (since they’re largely compatible and we don’t have Crowd installed). I do have one question: is there any way on the Openfire side to limit which groups can log into Openfire? That particular function (which exists in Crowd) doesn’t appear to exist in JIRA.
Unfortunately there’s no UI to setup the crowd connectino, so you’ll have to do a bit of manual leg-work.
First off you need a crowd.properties file (i have ours in /etc/openfire) something like this:
application.name=
application.password=
application.login.url=https://:9091/
crowd.server.url=https:///crowd/
session.isauthenticated=session.isauthenticated
session.tokenkey=session.tokenkey
session.validationinterval=0
session.lastvalidation=session.lastvalidation
http.proxy.host=
http.proxy.port=
http.proxy.username=
http.proxy.password=
http.max.connections=20
http.socket.timeout=20000
http.timeout=5000
Then you need to set a couple of server parameters (e.g. through the UI)
admin.authorizedGroups = crowd-administrators (or whatever group you want to administer openfire)
provider.admin.className = org.jivesoftware.openfire.crowd.CrowdAdminProvider
provider.auth.className = org.jivesoftware.openfire.crowd.CrowdAuthProvider
provider.group.className = org.jivesoftware.openfire.crowd.CrowdGroupProvider
provider.user.className = org.jivesoftware.openfire.crowd.CrowdUserProvider
crowd.groups.cache.ttl.seconds = 3600
crowd.users.cache.ttl.seconds = 3600
In case you have self-signed certificates for openfire and/or crowd, add at least the first one of these two:
clearspace.certificate.verify = false
clearspace.certificate.verify.root = false
That should make those errors go away…
That’s pretty much what i can tell i’ve setup specifically for getting openfire to work with Crowd (it happened over a period of time so i could have forgotten something
Cheers,
Dennis
Hi everyone,
I went through these configuration steps and everything seems to be working great with Crowd 2.7.1. Upon further review it seems as though we are having an issue with certain Crowd users not being able to login.
The pattern I’m seeing is, it seems like users with a capital letter in their username are the ones who are having login issues. When I click on their username in the openfire admin console, it shows something like: “The requested user was not found: B59527”
The user gets “Not authorized” when trying to login from the client. Other users w/o a capital letter in their username are working ok with Openfire/Crowd. The other strange anomoly is the aformentioned “B59527” user can login to all of the Atlassian tools ok.
I get the below error in the openfire logs. Any ideas?
2014.08.25 11:50:48 org.jivesoftware.openfire.crowd.CrowdVCardProvider - Unable to find user:b59527 for loading its vcard
org.jivesoftware.openfire.user.UserNotFoundException: User : ‘b59527’
at org.jivesoftware.openfire.crowd.CrowdUserProvider.getCrowdUser(CrowdUserProvide r.java:91)
at org.jivesoftware.openfire.crowd.CrowdVCardProvider.loadVCard(CrowdVCardProvider .java:68)
at org.jivesoftware.openfire.vcard.VCardManager.getOrLoadVCard(VCardManager.java:2 39)
at org.jivesoftware.openfire.vcard.VCardManager.getVCard(VCardManager.java:232)
at org.jivesoftware.openfire.handler.IQvCardHandler.handleIQ(IQvCardHandler.java:1 20)
at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:65)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:374)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:121)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:76)
at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:337)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:93)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:302)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:194)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Thread.java:722)
Hi Joel,
I think you’ve almost answered your own question judging from the error message, usernames are made lower case at some point and Crowd is probably case sensitive. I don’t recall if this is actually the case, but perhaps you can try changing a user from upper to lower case?
The fact that the user can login on the various atlassian products is probably an indication of either the API openfire is using, or openfire itself, is case sensitive.
Unfortunately i no longer have access to a setup with openfire and crowd, so i can’t really help troubleshoot the actual plugin.
Cheers,
Dennis
Hi Dennis,
I almost did indeed. Changing the username to all lowercase solved the issue! Everythings working great now. Other then sifting through 350 users and changing them to all lower case I’m good to go!
Thanks for the help!
-Joel