manifoldcf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kadri Atalay <atalay.ka...@gmail.com>
Subject Re: Which version of Solr have implements the Document Level Access Control
Date Mon, 02 May 2011 19:31:43 GMT
Hi Karl,

I noticed in the code that   NameNotFound exception is never being reached
because process is throwing internal exception, and this is never checked.
(see below)
Also, what is the reason for adding everyone group for each response ?
      theGroups.add("S-1-1-0");

When there is no groups or SID's returned, following return code is still
used..
      return new AuthorizationResponse(tokens,AuthorizationResponse*.**
RESPONSE_OK*);

Should I assume this code was tested against an Active Directory, and
working, and or should I start checking from the beginning every parameter
is entered. (see below)
For example, in the following code, DIGEST-MD5 GSSAPI is used for security
authentication, but user name and password is passed as a clear text.. and
not in the format they suggest in their documentation.

Thanks

Kadri

http://download.oracle.com/javase/jndi/tutorial/ldap/security/gssapi.html


    if (ctx == null)
    {
      // Calculate the ldap url first
      String ldapURL = "ldap://" + domainControllerName + ":389";

      Hashtable env = new Hashtable();

env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
      env.put(Context.SECURITY_AUTHENTICATION,"DIGEST-MD5 GSSAPI");
      env.put(Context.SECURITY_PRINCIPAL,userName);
      env.put(Context.SECURITY_CREDENTIALS,password);

      //connect to my domain controller
      env.put(Context.PROVIDER_URL,ldapURL);

      //specify attributes to be returned in binary format
      env.put("java.naming.ldap.attributes.binary","tokenGroups objectSid");



fakeuser@teqa

    //Search for objects using the filter
      NamingEnumeration answer = ctx.search(searchBase, searchFilter,
searchCtls);

answer    LdapSearchEnumeration  (id=6635)
    cleaned    false
    cont    Continuation  (id=6674)
    entries    Vector<E>  (id=6675)
    enumClnt    LdapClient  (id=6676)
        authenticateCalled    true
        conn    Connection  (id=6906)
        isLdapv3    true
        pcb    null
        pooled    false
        referenceCount    1
        unsolicited    Vector<E>  (id=6907)
    errEx    PartialResultException  (id=6677)
        cause    PartialResultException  (id=6677)
        detailMessage    "[LDAP: error code 10 - 0000202B: RefErr:
DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n


      ArrayList theGroups = new ArrayList();
      // All users get certain well-known groups
      theGroups.add("S-1-1-0");


answer    LdapSearchEnumeration  (id=7940)
    cleaned    false
    cont    Continuation  (id=7959)
    entries    Vector<E>  (id=7960)
    enumClnt    LdapClient  (id=7961)
    errEx    PartialResultException  (id=7962)
        cause    PartialResultException  (id=7962)
        detailMessage    "[LDAP: error code 10 - 0000202B: RefErr:
DSID-031006E0, data 0, 1 access points\n\tref 1: 'teqa'\n

      return new
AuthorizationResponse(tokens,AuthorizationResponse.RESPONSE_OK);


On Tue, Apr 26, 2011 at 12:54 PM, Karl Wright <daddywri@gmail.com> wrote:

> If a completely unknown user still comes back as existing, then it's
> time to look at how your domain controller is configured.
> Specifically, what do you have it configured to trust?  What version
> of Windows is this?
>
> The way LDAP tells you a user does not exist in Java is by an
> exception.  So this statement:
>
>      NamingEnumeration answer = ctx.search(searchBase, searchFilter,
> searchCtls);
>
> will throw the NameNotFoundException if the name doesn't exist, which
> the Active Directory connector then catches:
>
>    catch (NameNotFoundException e)
>    {
>      // This means that the user doesn't exist
>      return userNotFoundResponse;
>    }
>
> Clearly this is not working at all for your setup.  Maybe you can look
> at the DC's event logs, and see what kinds of decisions it is making
> here?  It's not making much sense to me at this point.
>
> Karl
>
> On Tue, Apr 26, 2011 at 12:45 PM, Kadri Atalay <atalay.kadri@gmail.com>
> wrote:
> > Get the same result with user doesn't exist
> > C:\OPT\security_example>curl
> > "
> http://localhost:8345/mcf-authority-service/UserACLs?username=fakeuser@fakedomain
> "
> > AUTHORIZED:TEQA-DC
> > TOKEN:TEQA-DC:S-1-1-0
> >
> > BTW, is there a command to get all users available in Active Directory,
> from
> > mcf-authority service, or other test commands to see if it's working
> > correctly ?
> >
> > Also, I set the logging level to finest from Solr Admin for
> > ManifoldCFSecurityFilter,but I don't see any logs created.. Is there any
> > other settings need to be tweaked ?
> >
> > Thanks
> >
> > Kadri
> >
> > On Tue, Apr 26, 2011 at 12:38 PM, Karl Wright <daddywri@gmail.com>
> wrote:
> >>
> >> One other quick note.  You might want to try a user that doesn't exist
> >> and see what you get.  It should be a USERNOTFOUND response.
> >>
> >> If that's indeed what you get back, then this is a relatively minor
> >> issue with Active Directory.  Basically the S-1-1-0 SID is added by
> >> the active directory authority, so the DC is actually returning an
> >> empty list of SIDs for the user with an unknown domain.  It *should*
> >> tell us the user doesn't exist, I agree, but that's clearly a problem
> >> only Active Directory can solve; we can't make that decision in the
> >> active directory connector because the DC may be just one node in a
> >> hierarchy.  Perhaps there's a Microsoft knowledge-base article that
> >> would clarify things further.
> >>
> >> Please let me know what you find.
> >> Karl
> >>
> >> On Tue, Apr 26, 2011 at 12:27 PM, Karl Wright <daddywri@gmail.com>
> wrote:
> >> > The method code from the Active Directory authority that handles the
> >> > LDAP query construction is below.  It looks perfectly reasonable to
> >> > me:
> >> >
> >> >  /** Parse a user name into an ldap search base. */
> >> >  protected static String parseUser(String userName)
> >> >    throws ManifoldCFException
> >> >  {
> >> >    //String searchBase =
> >> > "CN=Administrator,CN=Users,DC=qa-ad-76,DC=metacarta,DC=com";
> >> >    int index = userName.indexOf("@");
> >> >    if (index == -1)
> >> >      throw new ManifoldCFException("Username is in unexpected form
> >> > (no @): '"+userName+"'");
> >> >    String userPart = userName.substring(0,index);
> >> >    String domainPart = userName.substring(index+1);
> >> >    // Start the search base assembly
> >> >    StringBuffer sb = new StringBuffer();
> >> >    sb.append("CN=").append(userPart).append(",CN=Users");
> >> >    int j = 0;
> >> >    while (true)
> >> >    {
> >> >      int k = domainPart.indexOf(".",j);
> >> >      if (k == -1)
> >> >      {
> >> >        sb.append(",DC=").append(domainPart.substring(j));
> >> >        break;
> >> >      }
> >> >      sb.append(",DC=").append(domainPart.substring(j,k));
> >> >      j = k+1;
> >> >    }
> >> >    return sb.toString();
> >> >  }
> >> >
> >> > So I have to conclude that your Active Directory domain controller is
> >> > simply not caring what the DC= fields are, for some reason.  No idea
> >> > why.
> >> >
> >> > If you want to confirm this picture, you might want to create a patch
> >> > to add some Logging.authorityConnectors.debug statements at
> >> > appropriate places so we can see the actual query it's sending to
> >> > LDAP.  I'm happy to commit this debug output patch eventually if you
> >> > also want to create a ticket.
> >> >
> >> > Thanks,
> >> > Karl
> >> >
> >> > On Tue, Apr 26, 2011 at 12:17 PM, Kadri Atalay <
> atalay.kadri@gmail.com>
> >> > wrote:
> >> >> Yes, ManifoldCF is running with JCIFS connector, and using Solr 3.1
> >> >>
> >> >> response to first call:
> >> >> C:\OPT\security_example>curl
> >> >> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe"
> >> >> UNREACHABLEAUTHORITY:TEQA-DC
> >> >> TOKEN:TEQA-DC:DEAD_AUTHORITY
> >> >>
> >> >> response to fake domain call:
> >> >> C:\OPT\security_example>curl
> >> >>
> >> >> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=joe@fakedomain
> "
> >> >> AUTHORIZED:TEQA-DC
> >> >> TOKEN:TEQA-DC:S-1-1-0
> >> >>
> >> >> response to actual domain account call:
> >> >> C:\OPT\security_example>curl
> >> >>
> >> >> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=katalay_admin@teqa
> "
> >> >> AUTHORIZED:TEQA-DC
> >> >> TOKEN:TEQA-DC:S-1-1-0
> >> >>
> >> >> Looks like as long as there is a domain suffix, return is positive..
> >> >>
> >> >> Thanks
> >> >>
> >> >> Kadri
> >> >>
> >> >>
> >> >> On Tue, Apr 26, 2011 at 12:10 PM, Karl Wright <daddywri@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> So you are trying to extend the example in the book, correct, to
run
> >> >>> against active directory and the JCIFS connector?  And this is
with
> >> >>> Solr 3.1?
> >> >>>
> >> >>> The book was written for Solr 1.4.1, so it's entirely possible
that
> >> >>> something in Solr changed in relation to the way search components
> are
> >> >>> used.  So I think we're going to need to do some debugging.
> >> >>>
> >> >>> (1) First, to confirm sanity, try using curl against the mcf
> authority
> >> >>> service.  Try some combination of users to see how that works,
e.g.:
> >> >>>
> >> >>> curl
> >> >>> "http://localhost:8345/mcf-authority-service/UserACLs?username=joe"
> >> >>>
> >> >>> ...and
> >> >>>
> >> >>> curl
> >> >>>
> >> >>> "
> http://localhost:8345/mcf-authority-service/UserACLs?username=joe@fakedomain
> "
> >> >>>
> >> >>> ...and also the real domain name, whatever that is.  See if the
> access
> >> >>> tokens that come back look correct.  If they don't then we know
> where
> >> >>> there's an issue.
> >> >>>
> >> >>> If they *are* correct, let me know and we'll go to the next stage,
> >> >>> which would be to make sure the authority service is actually
> getting
> >> >>> called and the proper query is being built and run under Solr 3.1.
> >> >>>
> >> >>> Thanks,
> >> >>> Karl
> >> >>>
> >> >>> On Tue, Apr 26, 2011 at 11:59 AM, Kadri Atalay
> >> >>> <atalay.kadri@gmail.com>
> >> >>> wrote:
> >> >>> > Hi Karl,
> >> >>> >
> >> >>> > I followed the instructions, and for testing purposes set
> >> >>> > "stored=true"
> >> >>> > to
> >> >>> > be able to see the ACL values stored in Solr.
> >> >>> >
> >> >>> > But, when I run the search in following format I get peculiar
> >> >>> > results..
> >> >>> >
> >> >>> >
> >> >>> > :
> http://10.1.200.155:8080/solr/select/?q=*%3A*&AuthenticatedUserName=username
> >> >>> >
> >> >>> > Any user name without a domain name  ie AuthenticatedUserName=joe
> >> >>> > does
> >> >>> > not
> >> >>> > return any results (which is correct)
> >> >>> > But any user name with ANY domain name returns all the indexes
 ie
> >> >>> > AuthenticatedUserName=joe@fakedomain   (which is not correct)
> >> >>> >
> >> >>> > Any thoughts ?
> >> >>> >
> >> >>> > Thanks
> >> >>> >
> >> >>> > Kadri
> >> >>> >
> >> >>> > On Sun, Apr 24, 2011 at 7:08 PM, Karl Wright <daddywri@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Solr 3.1 is being clever here; it's seeing arguments coming
in
> that
> >> >>> >> do
> >> >>> >> not correspond to known schema fields, and presuming they
are
> >> >>> >> "automatic" fields.  So when the schema is unmodified,
you see
> >> >>> >> these
> >> >>> >> fields that Solr creates for you, with the attr_ prefix.
 They
> are
> >> >>> >> created as being "stored", which is not good for access
tokens
> >> >>> >> since
> >> >>> >> then you will see them in the response.  I don't know
if they are
> >> >>> >> indexed or not, but I imagine not, which is also not good.
> >> >>> >>
> >> >>> >> So following the instructions is still the right thing
to do, I
> >> >>> >> would
> >> >>> >> say.
> >> >>> >>
> >> >>> >> Karl
> >> >>> >>
> >> >>> >> On Fri, Apr 22, 2011 at 3:24 PM, Kadri Atalay
> >> >>> >> <atalay.kadri@gmail.com>
> >> >>> >> wrote:
> >> >>> >> > Hi Karl,
> >> >>> >> >
> >> >>> >> > There is one thing I noticed while following the
example in
> >> >>> >> > chapter
> >> >>> >> > 4.:
> >> >>> >> > Prior to making any changes into the schema.xml,
I was able to
> >> >>> >> > see
> >> >>> >> > the
> >> >>> >> > following security information in query responses:
> >> >>> >> > ie:
> >> >>> >> >
> >> >>> >> > <doc>
> >> >>> >> > -
> >> >>> >> > <arr name="attr_allow_token_document">
> >> >>> >> > <str>TEQA-DC:S-1-3-0</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-13</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-18</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-32-544</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-32-545</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-32-547</str>
> >> >>> >> > </arr>
> >> >>> >> > -
> >> >>> >> > <arr name="attr_allow_token_share">
> >> >>> >> > <str>TEQA-DC:S-1-1-0</str>
> >> >>> >> > <str>TEQA-DC:S-1-5-2</str>
> >> >>> >> > -
> >> >>> >> > <str>
> >> >>> >> > TEQA-DC:S-1-5-21-1212545812-2858578934-3563067286-1480
> >> >>> >> > </str>
> >> >>> >> > </arr>
> >> >>> >> > -
> >> >>> >> > <arr name="attr_content">
> >> >>> >> > -
> >> >>> >> > <str>
> >> >>> >> >                              Autonomy ODBC Fetch
Technical
> Brief
> >> >>> >> > 0506
> >> >>> >> > Technical Brief
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > But, after I modified the schema/xml, and added the
following
> >> >>> >> > fields,
> >> >>> >> >     <!-- Security fields -->
> >> >>> >> >     <field name="allow_token_document" type="string"
> >> >>> >> > indexed="true"
> >> >>> >> > stored="false" multiValued="true"/>
> >> >>> >> >     <field name="deny_token_document" type="string"
> >> >>> >> > indexed="true"
> >> >>> >> > stored="false" multiValued="true"/>
> >> >>> >> >     <field name="allow_token_share" type="string"
> indexed="true"
> >> >>> >> > stored="false" multiValued="true"/>
> >> >>> >> >     <field name="deny_token_share" type="string"
indexed="true"
> >> >>> >> > stored="false" multiValued="true"/>
> >> >>> >> >
> >> >>> >> > I longer see neither the attr_allow_token_document
  or the
> >> >>> >> > allow_token_document fields..
> >> >>> >> >
> >> >>> >> > Since same fields exist with attr_  prefix, should
we need to
> add
> >> >>> >> > these
> >> >>> >> > new
> >> >>> >> > field names into the schema file, or can we simply
change
> >> >>> >> > ManifoldSecurity
> >> >>> >> > to use attr_ fields ?
> >> >>> >> >
> >> >>> >> > Also, when Solr is running under Tomcat, I have to
re-start the
> >> >>> >> > Solr
> >> >>> >> > App, or
> >> >>> >> > re-start Tomcat to see the newly added indexes..
> >> >>> >> >
> >> >>> >> > Any thoughts ?
> >> >>> >> >
> >> >>> >> > Thanks
> >> >>> >> >
> >> >>> >> > Kadri
> >> >>> >> >
> >> >>> >> > On Fri, Apr 22, 2011 at 12:53 PM, Karl Wright
> >> >>> >> > <daddywri@gmail.com>
> >> >>> >> > wrote:
> >> >>> >> >>
> >> >>> >> >> I don't believe Solr has yet officially released
document
> access
> >> >>> >> >> control, so you will need to use the patch for
ticket 1895.
> >> >>> >> >> Alternatively, the ManifoldCF in Action chapter
4 example has
> an
> >> >>> >> >> implementation based on this ticket.  You can
get the code for
> >> >>> >> >> it at
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >>
> https://manifoldcfinaction.googlecode.com/svn/trunk/edition_1/security_example
> .
> >> >>> >> >>
> >> >>> >> >> Thanks,
> >> >>> >> >> Karl
> >> >>> >> >>
> >> >>> >> >>
> >> >>> >> >> On Fri, Apr 22, 2011 at 11:45 AM, Kadri Atalay
> >> >>> >> >> <atalay.kadri@gmail.com>
> >> >>> >> >> wrote:
> >> >>> >> >> > Hello,
> >> >>> >> >> >
> >> >>> >> >> > Does anyone know which version of Solr have
implements the
> >> >>> >> >> > Document
> >> >>> >> >> > Level
> >> >>> >> >> > Access Control, or has it implemented (partially
or fully) ?
> >> >>> >> >> > Particularly issue #s 1834, 1872, 1895
> >> >>> >> >> >
> >> >>> >> >> > Thanks
> >> >>> >> >> >
> >> >>> >> >> > Kadri
> >> >>> >> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >
> >
>

Mime
View raw message