[SASL] Authentication Level = Strong

[Enrique Rodriguez <en...@gmail.com>]

Hi, Directory developers,

I committed 'strong' X.501 authenticationLevel support to the SASL
branch.  So, if you Bind with any of the SASL mechanisms (CRAM-MD5,
DIGEST-MD5, GSSAPI), your user principal for acquiring LdapContexts
now has the authenticationLevel set to 'strong'.

I mention this because I'm not sure how to *really* test it.  All the
current tests pass.  I'm not yet familiar with the ACI subsystem, so
any pointers to tests that could be used as a starting point to test
access based on authentication level would be appreciated.
Alternatively, those of you more familiar with ACI can now work on
tests that take advantage of this new capability.

Also, besides access control, is there anywhere else the
authentication level matters?

Enrique

Re: [SASL] Authentication Level = Strong

[Enrique Rodriguez <en...@gmail.com>]

On 4/8/07, Ersin Er <er...@gmail.com> wrote:
> Hi Enrique,
>
> This is great news! Is there any test cases that we can build some ACI
> tests on top of? (I did not see it in your last commit but maybe I
> missed it in your previous commits.)

>From previous commits I have SaslBindTest and SaslGssapiTest, both in
server-unit.

Enrique

Re: [SASL] Authentication Level = Strong

[Enrique Rodriguez <en...@gmail.com>]

On 4/8/07, Ersin Er <er...@gmail.com> wrote:
> Integration tests in apacheds-sasl-branch are failing here with such
> an exception:
>
> Any idea?

I've seen errors like this when I had trunk and branch writing to the
same jars in the local M2 repo.  I recommend flushing the local M2
repo, at least for the directory groupId.  I maintain two physically
separate development workstations, for both the above M2 issues and
some Eclipse workspace issues.

Enrique

Re: [SASL] Authentication Level = Strong

[Ersin Er <er...@gmail.com>]

Integration tests in apacheds-sasl-branch are failing here with such
an exception:

Running org.apache.directory.server.core.schema.SchemaServiceITest
Tests run: 13, Failures: 0, Errors: 3, Skipped: 0, Time elapsed:
29.299 sec <<< FAILURE!
org.apache.maven.surefire.booter.SurefireExecutionException:
org/apache/directory/server/core/configuration/Configuration; nested
exception is java.lang.NoClassDefFoundError:
org/apache/directory/server/core/configuration/Configuration
java.lang.NoClassDefFoundError:
org/apache/directory/server/core/configuration/Configuration
        at java.lang.Class.getDeclaredMethods0(Native Method)
        at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
        at java.lang.Class.getMethod0(Class.java:2670)
        at java.lang.Class.getMethod(Class.java:1603)
        at org.apache.maven.surefire.junit.JUnitTestSet.createInstanceFromSuiteMethod(JUnitTestSet.java:173)
        at org.apache.maven.surefire.junit.JUnitTestSet.constructTestObject(JUnitTestSet.java:137)
        at org.apache.maven.surefire.junit.JUnitTestSet.getTestCount(JUnitTestSet.java:244)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:101)
        at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:147)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:64)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:182)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:743)

Any idea?


On 4/8/07, Ersin Er <er...@gmail.com> wrote:
> Hi Enrique,
>
> This is great news! Is there any test cases that we can build some ACI
> tests on top of? (I did not see it in your last commit but maybe I
> missed it in your previous commits.)
>
> --
> Ersin
>
> On 4/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > Hi, Directory developers,
> >
> > I committed 'strong' X.501 authenticationLevel support to the SASL
> > branch.  So, if you Bind with any of the SASL mechanisms (CRAM-MD5,
> > DIGEST-MD5, GSSAPI), your user principal for acquiring LdapContexts
> > now has the authenticationLevel set to 'strong'.
> >
> > I mention this because I'm not sure how to *really* test it.  All the
> > current tests pass.  I'm not yet familiar with the ACI subsystem, so
> > any pointers to tests that could be used as a starting point to test
> > access based on authentication level would be appreciated.
> > Alternatively, those of you more familiar with ACI can now work on
> > tests that take advantage of this new capability.
> >
> > Also, besides access control, is there anywhere else the
> > authentication level matters?
> >
> > Enrique
> >
>
>
> --
> Ersin
>


-- 
Ersin

Re: [SASL] Authentication Level = Strong

[Ersin Er <er...@gmail.com>]

Hi Enrique,

This is great news! Is there any test cases that we can build some ACI
tests on top of? (I did not see it in your last commit but maybe I
missed it in your previous commits.)

-- 
Ersin

On 4/8/07, Enrique Rodriguez <en...@gmail.com> wrote:
> Hi, Directory developers,
>
> I committed 'strong' X.501 authenticationLevel support to the SASL
> branch.  So, if you Bind with any of the SASL mechanisms (CRAM-MD5,
> DIGEST-MD5, GSSAPI), your user principal for acquiring LdapContexts
> now has the authenticationLevel set to 'strong'.
>
> I mention this because I'm not sure how to *really* test it.  All the
> current tests pass.  I'm not yet familiar with the ACI subsystem, so
> any pointers to tests that could be used as a starting point to test
> access based on authentication level would be appreciated.
> Alternatively, those of you more familiar with ACI can now work on
> tests that take advantage of this new capability.
>
> Also, besides access control, is there anywhere else the
> authentication level matters?
>
> Enrique
>


-- 
Ersin