OpenAM could have some interesting stuff: http://forgerock.com/openam.html
Jan On 4. okt. 2010, at 10:48, <karl.wri...@nokia.com> wrote: > Is there Kerberos support in this offering? That's what's missing. LDAP > support is actually built into java, and the Active Directory authority makes > use of it. So all we need is the authentication piece. > > Karl > > ________________________________________ > From: ext Lance Norskog [goks...@gmail.com] > Sent: Sunday, October 03, 2010 10:58 PM > To: dev@lucene.apache.org > Subject: Re: FW: Solr and LCF security at query time > > www.openldap.org > > Haven't used it. Here's the License: > > http://www.openldap.org/software/release/license.html > > karl.wri...@nokia.com wrote: >> Looking around for no-Apache java-only solutions to the AD authentication >> problem, it seems to me that what we mainly have available is JAAS plus the >> following JAAS login module: >> >> com.sun.security.auth.module.Krb5LoginModule >> >> ... which should permit AD authentication to take place, if properly >> configured. >> So, we *could* stipulate that the search component receive credentials, >> somehow, upon being called, and then authenticate each time. (There's a >> ticket cache involved, so this is not as insane as it sounds). >> >> But this architecture option makes me twitchy because I am unclear how >> exactly this would help Tomcat interact with the browser to manage signon >> for a web application. So it might be better to push the authentication >> itself upstream into a module meant to be plugged into Tomcat, and have Solr >> just receive and deal with the resulting ticket, and/or an authenticated, >> domain-qualified user name. The task of the LCF Solr search component or >> filter would then be to do the following: >> >> (1) Get hold of the ticket/authenticated user name, which will probably come >> in as some attribute to the search that's presented to Solr. (Someone needs >> to specify what this attribute is called still). >> (2) Invoke a configured LCF authority service with that user name, via http, >> and get back a list of access tokens for the user >> (3) Form the search expression with the user's access tokens (if it's a >> search component), or filter the results using those access tokens (if it's >> a filter), remembering that every document that's participating in security >> should have __ACCESS_TOKEN__document and __DENY_TOKEN__document metadata >> >> I've also been pondering whether which we should build: a search component >> or filter? I think there are advantages to both, so I think we should build >> both, and let people use what they need. >> >> I think the technical aspects of building the Solr component are well >> understood by this group, so the only open issue remains how to build a >> JAAS-based AD authentication module for tomcat that would do what we needed. >> I'll be doing more research as time permits... >> >> Karl >> >> ________________________________________ >> From: Wright Karl (Nokia-S/Cambridge) >> Sent: Wednesday, April 21, 2010 8:02 PM >> To: connectors-u...@incubator.apache.org; lucene-...@apache.org; >> connectors-...@incubator.apache.org >> Subject: RE: FW: Solr and LCF security at query time >> >> Hi Peter, >> >> I just committed the promised changes to the LCF Solr output connector. >> >> ACL metadata will now be posted to the Solr Http interface along with the >> document as the two following fields: >> >> __ACCESS_TOKEN__document >> __DENY_TOKEN__document >> >> There will, of course, potentially be multiple values for each of these two >> fields. >> >> Hope this helps, >> Karl >> >> ________________________________ >> From: ext Peter Sturge [mailto:peter.stu...@googlemail.com] >> Sent: Tuesday, April 20, 2010 6:51 PM >> To: connectors-u...@incubator.apache.org >> Subject: Re: FW: Solr and LCF security at query time >> >> Hi Karl, >> >> Thanks for the info. I'll have a look at the link and try to take in as much >> sugar as my insulin levels will handle... >> It sounds like the necessary interface(s) are already in LCF - just a matter >> of implementing them in the Solr 1872 plugin. >> I'll need to digest the LCF stuff to get to grips with it..please bear with >> me while I do that... >> >> When you say: >> The LCF solr output connection doesn't yet do this, but it is trivial for >> me to make that happen. >> Do you mean a mechanism by which solr.war can get url et al info from its >> parent container (Tomcat, Jetty etc.), or have I misinterpreted this? >> >> >> Thanks, >> Peter >> >> >> >> >> On Tue, Apr 20, 2010 at 11:05 >> PM,<karl.wri...@nokia.com<mailto:karl.wri...@nokia.com>> wrote: >> Hi Peter, >> >> I'm the principal committer for LCF, but I don't know as much about Solr as >> I ought to, so it sounds like a potentially productive collaboration. >> >> LCF does exactly what you are looking for - the only issue at all is that >> you need to fetch a URL from a webapp to get what you are looking for. The >> "plugs" are all inside LCF for different kinds of repositories. Here's a >> link that might help with drinking the LCF "koolaid", as it were: >> https://cwiki.apache.org/confluence/display/CONNECTORS/Lucene+Connectors+Framework+concepts >> >> The url would be something like this (on a locally installed tomcat-based >> LCF instance): >> >> http://localhost:8080/lcf-authority-service/useracls?username=someusern...@somedomain.com >> >> ... and this fetch returns something like: >> >> TOKEN:xxxxxxx >> TOKEN:yyyyyyy >> TOKEN:zzzzzzz >> .... >> >> ... which represent the amalgamated tokens for all of the defined >> authorities, and by some strange coincidence ( ;-) ) are compatible with >> certain pieces of metadata that have been passed into Solr with each >> document - one set of Allow tokens, and a second set of Deny tokens. The >> LCF solr output connection doesn't yet do this, but it is trivial for me to >> make that happen. >> >> Does this sound plausible to you? >> >> Karl >> >> >> ________________________________ >> From: ext Peter Sturge >> [mailto:peter.stu...@googlemail.com<mailto:peter.stu...@googlemail.com>] >> Sent: Tuesday, April 20, 2010 5:41 PM >> To: >> connectors-u...@incubator.apache.org<mailto:connectors-u...@incubator.apache.org>; >> dev@lucene.apache.org<mailto:dev@lucene.apache.org> >> >> Subject: Re: FW: Solr and LCF security at query time >> >> Hi Karl, >> >> Integrating LCF to get external token support for SOLR-1872 sounds very >> interesting indeed. I don't know anything about LCF, but one of the things I >> was planning for SOLR-1872 is to make acl.xml (or rather its behaviour) >> 'pluggable' - i.e. it would just be one of a series of plugins that could be >> used for obtaining back-end authentication information. >> >> If you're good with LCF, perhaps we could work together to build this in. >> One of the first things would be defining an interface that would be as easy >> as possible to plug LCF into. Have you any suggestions/insight on this front? >> >> Many thanks, >> Peter >> >> >> >> On Tue, Apr 20, 2010 at 4:08 >> PM,<karl.wri...@nokia.com<mailto:karl.wri...@nokia.com>> wrote: >> SOLR-1872 looks exactly like what I was envisioning, from the search query >> perspective, although instead of the acl xml file you specify LCF stipulates >> you would dynamically query the lcf-authority-service servlet for the access >> tokens themselves. That would get you support for AD, Documentum, LiveLink, >> Meridio, and Memex for free. It seems likely that this component could be >> modified to work with LCF with minor effort. >> >> The missing component still seems to be AD authentication, which needs a >> solution. >> >> Karl >> >> ________________________________ >> From: ext Peter Sturge >> [mailto:peter.stu...@googlemail.com<mailto:peter.stu...@googlemail.com>] >> Sent: Tuesday, April 20, 2010 10:44 AM >> To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> >> Subject: Re: FW: Solr and LCF security at query time >> >> If you want to do this completely within Solr, have a look at: >> SOLR-1834 and SOLR-1872. These use a SearchComponent plugin for Solr. >> >> Thanks, >> Peter >> >> >> >> On Tue, Apr 20, 2010 at 1:25 >> PM,<karl.wri...@nokia.com<mailto:karl.wri...@nokia.com>> wrote: >> FYI >> >> ________________________________ >> From: Wright Karl (Nokia-S/Cambridge) >> Sent: Tuesday, April 20, 2010 8:16 AM >> To: 'dominique.bej...@eolya.fr<mailto:dominique.bej...@eolya.fr>' >> Cc: 'solr-...@apache.org<mailto:solr-...@apache.org>'; >> 'connectors-...@incubator.apache.org<mailto:connectors-...@incubator.apache.org>'; >> >> 'connectors-u...@incubator.apache.org<mailto:connectors-u...@incubator.apache.org>' >> Subject: RE: Solr and LCF security at query time >> >> Dominique, >> >> Yes, I am aware of this ticket and contribution. Luckily LCF establishes a >> powerful multi-repository security model, even though it doesn't yet do the >> final step of enforcing that model at the search end. LCF allows you to >> define multiple authorities to operate against disparate repositories, and >> use the appropriate authority to secure any given document. The solr people >> are aware of this design, which addresses the issues raised by SOLR-1834 >> very nicely. However, as I said before, time is a problem, and the work >> still needs to be done. >> >> I suggest you read up on the actual security model of LCF, and perhaps >> experiment with that and the SOLR-1834 contribution, to see if there is >> common ground. One thing we've learned at MetaCarta is that post-filtering >> for security purposes is expensive, and it is better to modify the queries >> themselves to restrict the results, if possible. I'm not sure which >> approach SOLR-1834 takes, although it sounds like it might be the filtering >> approach. Still, it would be better than nothing. >> >> Please let me know what you find out. >> >> Thanks, >> Karl >> >> ________________________________ >> From: ext Dominique Bejean >> [mailto:dominique.bej...@eolya.fr<mailto:dominique.bej...@eolya.fr>] >> Sent: Tuesday, April 20, 2010 8:03 AM >> To: Wright Karl (Nokia-S/Cambridge) >> Cc: >> connectors-u...@incubator.apache.org<mailto:connectors-u...@incubator.apache.org>; >> >> connectors-...@incubator.apache.org<mailto:connectors-...@incubator.apache.org> >> Subject: Re: Solr and LCF security at query time >> >> Karl, >> >> Thank you for your reply. >> >> I made some research today and I found this : >> http://freesurf001.appspot.com/issues.apache.org/jira/browse/SOLR-1834 >> http://demo.findwise.se:8880/SolrSecurity/ >> >> Sorl security model have to be able to filter result list with items coming >> from various sources at the same time (livelink, documentum, file system, >> ...). Big subject :) >> >> Dominique >> >> >> Le 20/04/10 13:34, karl.wri...@nokia.com<mailto:karl.wri...@nokia.com> a >> écrit : >> Hi Dominique, >> >> At the moment, in order to enforce the LCF security model within >> Lucene/Solr, you will need to build this functionality into whatever client >> you are using to display the Lucene search results. Specifically, you would >> need to take the following steps: >> >> (1) Have your users access your search client through Apache. >> (2) Use the Apache module mod_auth_kerb, combined with LCF's >> mod_authz_annotate, to cause authorization HTTP headers to be transmitted to >> the client webapp. >> (3) Have your client webapp alter whatever queries it is doing, to add an >> appropriate query clause for each of the access tokens transmitted in the >> headers. >> >> (This is how it is done at MetaCarta.) >> >> Alternatively, you may find a way to do this completely with a web >> application under a Java app server such as Tomcat. I have not yet done the >> research to find out whether this is a feasible alternative. Effectively, >> what you need something like mod_auth_kerb to do is to authenticate your >> user against Active Directory, or whomever the authenticator ought to be. >> JAAS may be helpful here. >> >> There are, of course, intentions to fill out the missing pieces more >> completely and transparently via a Solr search plugin and/or filter. What >> has been lacking is time. If you are in a position to do development in >> this area, we're happy to have any assistance you might provide. >> >> Thanks, >> Karl >> ________________________________ >> From: ext Dominique Bejean [mailto:dominique.bej...@eolya.fr] >> Sent: Tuesday, April 20, 2010 5:06 AM >> To: >> connectors-u...@incubator.apache.org<mailto:connectors-u...@incubator.apache.org> >> Subject: Solr and LCF security at query time >> >> Hi, >> >> I don't see in LCF wiki how Solr and LCF works together at query time in >> order to remove from the result list the items the user is not allowed to >> access. >> >> In >> http://cwiki.apache.org/CONNECTORS/lucene-connectors-framework-concepts.html, >> I just see these sentences : >> >> " Once all these documents and their access tokens are handed to the search >> engine, it is the search engine's job to enforce security by excluding >> inappropriate documents from the search results. For Lucene, this >> infrastructure is expected to be built on top of Lucene's generic metadata >> abilities, but has not been implemented at this time." >> >> I am not sure to understand. Does this mean that for the moment, it is not >> possible for Solr to apply security by using an Authority Connector ? >> >> Dominique >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
