You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Stefan Guggisberg <st...@gmail.com> on 2005/02/25 18:15:26 UTC
JAAS support
folks,
i committed a first implementation of generic JAAS support
(rev155344). jackrabbit is now making use of standard JAAS mechanisms
(-> configurable LoginModules) to authenticate users. the relevant code
is in RepositoryImpl.login() and in the code in the 'security' package.
there's a SimpleLoginModule and a SimpleAccessManager in the
security package. those don't do anything right now and are intended
as fallbacks.
in case you run into a java.lang.SecurityException (LoginConfig not found)
when you start jackrabbit you have to set the system property
java.security.auth.login.config with the path to your JAAS config
file.
i added a sample config (src/conf/jaas.config). this config specifies
the SimpleLoginModule for the "Jackrabbit" application.
now it should be very easy to use LDAP-based authorization with
jackrabbit.
next steps:
- make the AccessManager and name of the config entry
configurable (in repository.xml)
- provide very simple username/password authorization
as sample/fallback.
cheers
stefan
Re: JAAS support
Posted by Bertrand LEGA <le...@yahoo.fr>.
Index: java/org/apache/jackrabbit/core/RepositoryImpl.java
===================================================================
--- java/org/apache/jackrabbit/core/RepositoryImpl.java (revision 156033)
+++ java/org/apache/jackrabbit/core/RepositoryImpl.java (working copy)
@@ -52,7 +52,10 @@
import javax.jcr.observation.EventIterator;
import javax.jcr.observation.EventListener;
import javax.security.auth.login.LoginContext;
+
+import java.io.BufferedWriter;
import java.io.File;
+import java.io.FileWriter;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
@@ -97,6 +100,11 @@
// configuration of the repository
private final RepositoryConfig repConfig;
+ /**
+ * The name of the jaas config system property.
+ */
+ private static final String SYS_JAAS_CONFIG = "java.security.auth.login.config";
+
// the master filesystem
private final FileSystem repStore;
@@ -648,6 +656,28 @@
//-----------------------------------------------------------< Repository >
/**
* @see Repository#login(Credentials, String)
+ * As the current implementation uses the <code>com.sun.security.auth.login.ConfigFile</code>
+ * as the current provider for the login configuration, the application
+ * needs to have the environment variable ??? to be set
+ * with the config file.
+ * Example :
+ * <code>
+ * System.setProperty("java.security.auth.login.config", "c:\\temp\\jaas.config" ) ;
+ * </code>
+ * The file C:\temp\jaas.config is supposed to give the login module implementation.
+ *
+ * Exmaple of jaas.config
+ * <code>
+ * Jackrabbit {
+ * org.apache.jackrabbit.core.security.SimpleLoginModule required;
+ * };
+ * </code>
+ *
+ * All that is very boring and breaks compatibility.
+ * So I added code to create this file in the repository homedir if not present, with the default content
+ * as described above and set the env property accordingly.
+ * Of course, if the property is already set, nothing is done.
+ *
*/
public Session login(Credentials credentials, String workspaceName)
throws LoginException, NoSuchWorkspaceException, RepositoryException {
@@ -664,6 +694,41 @@
throw new NoSuchWorkspaceException(workspaceName);
}
+ // Generating file + set the property to support the login module
+ if (System.getProperty(SYS_JAAS_CONFIG) == null ) {
+ // Create the file
+
+ String jaasConfigFilepath = repConfig.getHomeDir() + File.separator +"jaasgenerated.config" ;
+ File jaasConfigFile = new File( jaasConfigFilepath ) ;
+ BufferedWriter writer = null ;
+ try {
+ writer = new BufferedWriter( new FileWriter( jaasConfigFilepath )) ;
+ StringBuffer content = new StringBuffer() ;
+ content.append( "Jackrabbit { \n" ) ;
+ content.append( " org.apache.jackrabbit.core.security.SimpleLoginModule required; \n" ) ;
+ content.append( " };\n" ) ;
+ writer.write( content.toString() ) ;
+ writer.flush() ;
+ log.info( "The JAAS configuration file '" + jaasConfigFile.getAbsolutePath() + "' has been generated.") ;
+ } catch (IOException e) {
+ // Exception
+ log.debug("The file " + jaasConfigFilepath + "failed to be generated. Erreur : " + e.getMessage() );
+ }
+ finally
+ {
+ if( writer != null )
+ {
+ try {
+ writer.close() ;
+ } catch (IOException e1) {
+ // ok
+ }
+ }
+ }
+ // Set the property
+ System.setProperty(SYS_JAAS_CONFIG, jaasConfigFile.getAbsolutePath() );
+ }
+
CredentialsCallbackHandler cbHandler =
new CredentialsCallbackHandler(credentials);
LoginContext lc;
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
On Mon, 07 Mar 2005 18:53:03 +0100, Sylvain Wallez <sy...@apache.org> wrote:
>
> BTW, if nobody objects, I volunteer for this change to exercise my
> Jackrabbit committer status :-)
sure, go ahead :)
cheers
stefan
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
On 4/20/05, Sylvain Wallez <sy...@apache.org> wrote:
> Stefan Guggisberg wrote:
>
> >hi sylvain,
> >
> >On 3/7/05, Sylvain Wallez <sy...@apache.org> wrote:
> >
> >
> >>No, it currently doesn't work. But having pluggable authentication is
> >>planned and should come soon. We're waiting for Jukka to finish the
> >>ongoing configuration refactoring before adding this new feature.
> >>
> >>BTW, if nobody objects, I volunteer for this change to exercise my
> >>Jackrabbit committer status :-)
> >>
> >>
> >
> >i guess you were too busy lately and didn't find the time to do the changes.
> >do you see a chance that you can do them in the next couple of days? if not,
> >do you want to do them later or should we do i?
> >
> >
>
> Well, know what? I wrote these changes no later than this morning and
> was awaiting svn and the mail to come back :-)
>
> Mail seems ok now, but svn doesn't answer yet. I'll commit these changes
> ASAP.
>
> Basically, my changes add a new <LoginModule class="..."/> within the
> <Security> configuration element. If LoginModule is present, we use it,
> otherwise we use the standard JAAS mechanism.
perfect! :)
thanks,
stefan
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://apache.org/~sylvain http://anyware-tech.com
> Apache Software Foundation Member Research & Technology Director
>
>
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Roy T. Fielding wrote:
> On Apr 20, 2005, at 12:05 PM, Sylvain Wallez wrote:
>
>> svn is up again, just for me to realize that I don't have karma for
>> jackrabbit in the svn authorization file :-/
>
>
> That's bizarre -- I was sure that I added everyone on day 1.
>
>> I guess Roy should be able to fix this!
>
>
> Fixed,
Thanks. Commit done!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JAAS support
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 20, 2005, at 12:05 PM, Sylvain Wallez wrote:
> svn is up again, just for me to realize that I don't have karma for
> jackrabbit in the svn authorization file :-/
That's bizarre -- I was sure that I added everyone on day 1.
> I guess Roy should be able to fix this!
Fixed,
....Roy
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Stefan Guggisberg wrote:
>> i guess you were too busy lately and didn't find the time to do the
>> changes. do you see a chance that you can do them in the next couple
>> of days? if not, do you want to do them later or should we do i?
>
>
> Well, know what? I wrote these changes no later than this morning and
> was awaiting svn and the mail to come back :-)
>
> Mail seems ok now, but svn doesn't answer yet. I'll commit these
> changes ASAP.
svn is up again, just for me to realize that I don't have karma for
jackrabbit in the svn authorization file :-/
I guess Roy should be able to fix this!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Stefan Guggisberg wrote:
>hi sylvain,
>
>On 3/7/05, Sylvain Wallez <sy...@apache.org> wrote:
>
>
>>No, it currently doesn't work. But having pluggable authentication is
>>planned and should come soon. We're waiting for Jukka to finish the
>>ongoing configuration refactoring before adding this new feature.
>>
>>BTW, if nobody objects, I volunteer for this change to exercise my
>>Jackrabbit committer status :-)
>>
>>
>
>i guess you were too busy lately and didn't find the time to do the changes.
>do you see a chance that you can do them in the next couple of days? if not,
>do you want to do them later or should we do i?
>
>
Well, know what? I wrote these changes no later than this morning and
was awaiting svn and the mail to come back :-)
Mail seems ok now, but svn doesn't answer yet. I'll commit these changes
ASAP.
Basically, my changes add a new <LoginModule class="..."/> within the
<Security> configuration element. If LoginModule is present, we use it,
otherwise we use the standard JAAS mechanism.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
hi sylvain,
On 3/7/05, Sylvain Wallez <sy...@apache.org> wrote:
> No, it currently doesn't work. But having pluggable authentication is
> planned and should come soon. We're waiting for Jukka to finish the
> ongoing configuration refactoring before adding this new feature.
>
> BTW, if nobody objects, I volunteer for this change to exercise my
> Jackrabbit committer status :-)
i guess you were too busy lately and didn't find the time to do the changes.
do you see a chance that you can do them in the next couple of days? if not,
do you want to do them later or should we do i?
cheers
stefan
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Andy Depue wrote:
>I respect your position and can certainly see advantages (pros). I was simply
>thinking out loud...
>
>
No problem. It's just me that is under high pressure lately (lot of
work) and sometimes quick at throwing strong arguments in the discussion ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JAAS support
Posted by Andy Depue <an...@marathon-man.com>.
I respect your position and can certainly see advantages (pros). I was simply
thinking out loud...
- Andy
On Tuesday 08 March 2005 10:35 am, Sylvain Wallez wrote:
>
> Have a look at the LoginModule docs [1]. Does it look so complicated?
>
> Furthermore, using this standard interface potentially allows your
> specific authentication scheme to become part of a larger picture in a
> JAAS-enabled environment. You've written a LoginModule adapter for your
> stuff to be able to use Jackrabbit? Now you can use it everywhere.
> Either in the standard java security file, but also as a configuration
> of other libraries that hopefully rely on the JAAS standard interfaces
> and allow you to provide them with a custom LoginModule.
>
> Sylvain
>
> [1]
> http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/spi/LoginModule
>.html
Re: JAAS support
Posted by Brian Moseley <bc...@osafoundation.org>.
Jukka Zitting wrote:
> You can find one at Gmane:
>
> http://gmane.org/info.php?group=gmane.comp.apache.jackrabbit.devel
>
> The pluggable authentication thread is at:
>
> http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/902
perfect. thanks all.
Re: JAAS support
Posted by Jukka Zitting <jz...@yukatan.fi>.
Brian Moseley asked:
> does a web interface to the list archive exist, or is my
> only option to download the raw archive?
You can find one at Gmane:
http://gmane.org/info.php?group=gmane.comp.apache.jackrabbit.devel
The pluggable authentication thread is at:
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/902
BR,
Jukka Zitting
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, 08 Mar 2005 09:08:09 -0800, Brian Moseley <bc...@osafoundation.org> wrote:
> Tobias Strasser wrote:
> > read the plugable authentication thread, please. this solves all your
> > problems :-)
>
> does a web interface to the list archive exist, or is my
> only option to download the raw archive?
there's an archive at:
http://dir.gmane.org/gmane.comp.apache.jackrabbit.devel
to browse it:
http://news.gmane.org/gmane.comp.apache.jackrabbit.devel
cheers
stefan
>
Re: JAAS support
Posted by Brian Moseley <bc...@osafoundation.org>.
Tobias Strasser wrote:
> read the plugable authentication thread, please. this solves all your
> problems :-)
does a web interface to the list archive exist, or is my
only option to download the raw archive?
Re: JAAS support
Posted by Tobias Strasser <to...@gmail.com>.
read the plugable authentication thread, please. this solves all your
problems :-)
cheers, tobi
Re: JAAS support
Posted by "Suhail M. Ahmed" <il...@mac.com>.
I couldn't have put it better Sylvain. After prototyping with different
architectures, I have settled on integrating The rabbit with SJAS 8.1.
SJAS provides system wide security service as a J2EE app server.
Practically, this has meant removing the LoginContext dependency from
RepositoryImpl and use a servlet and loginForm to associate the Subject
with the Repository session. As a standalone repository, the current
implementation is I believe the hassle free way to go. I personally
feel that Jackrabbit should endeavor to give the user a stress free
experience out of the box so that they can stress out the API. The
current implementation is well on the way to becoming such.
However if you consider embedding Jackrabbit into a container, It is
quite likely that the container will be responsible for dealing with
the LoginContext. Take Catalina for instance, if one follows the
standard login scheme, then Tomcat delegates the login to the
underlying Realm (I use the JAASRealm). It performs the authentication
and instances the GenericPrincipal. The application layer has no
standard hook on these objects except via getUserPrincipal and
isUserInRole. In my own experience in tying JackRabbit to SJAS, I had
two choices; either re-authenticate the user by providing a dummy
single sign on in a custom LoginModule or embed the Authentication
context inside JackRabbit. I chose the latter route. It is testament to
the cohesiveness of the API and the implementation that I could manage
this quite easily because Jackrabbits JAAS implementation allowed me to
easily disable it and retrofit it to rely on SJAS for authentication.
I think the main challenge is going to be in Authorization. Every web
application worth its salt seems to have their own Authorization and
Authentication API. I will try and rely on JACC for this bit. Again the
issues will be the same, how to pass the JACC context into JackRabbit
AccessManager. I suspect the solution the JackRabbit team will come up
with will be as transparent as they have for RepositoryImpl.login.
As ever, my fast depreciating 2 cents
Suhail
On Mar 8, 2005, at 7:35 PM, Sylvain Wallez wrote:
> Andy Depue wrote:
>
>> On Tuesday 08 March 2005 03:32 am, Dominique Pfister wrote:
>>
>
> <snip/>
>
>>> IMO, the concept of JAAS is abstract enough to handle this situation
>>> and
>>> it should be possible to implement a custom LoginModule that will add
>>> Principal information to the Subject being authenticated in such a
>>> way
>>> that authorization calls made on the Subject will actually be
>>> forwarded
>>> to Acegi.
>>>
>>
>> What you're saying is if someone wants to adapt Jackrabbit to their
>> own authentication scheme, they are going to have to create a JAAS
>> adapter/implementation? This is doable, no doubt. But Ben's idea
>> has the advantage of being simple.
>>
>
> Have a look at the LoginModule docs [1]. Does it look so complicated?
>
> Furthermore, using this standard interface potentially allows your
> specific authentication scheme to become part of a larger picture in a
> JAAS-enabled environment. You've written a LoginModule adapter for
> your stuff to be able to use Jackrabbit? Now you can use it
> everywhere. Either in the standard java security file, but also as a
> configuration of other libraries that hopefully rely on the JAAS
> standard interfaces and allow you to provide them with a custom
> LoginModule.
>
> Sylvain
>
> [1]
> http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/spi/
> LoginModule.html
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Andy Depue wrote:
>On Tuesday 08 March 2005 03:32 am, Dominique Pfister wrote:
>
>
<snip/>
>>IMO, the concept of JAAS is abstract enough to handle this situation and
>>it should be possible to implement a custom LoginModule that will add
>>Principal information to the Subject being authenticated in such a way
>>that authorization calls made on the Subject will actually be forwarded
>>to Acegi.
>>
>>
>
>What you're saying is if someone wants to adapt Jackrabbit to their own
>authentication scheme, they are going to have to create a JAAS
>adapter/implementation? This is doable, no doubt. But Ben's idea has the
>advantage of being simple.
>
Have a look at the LoginModule docs [1]. Does it look so complicated?
Furthermore, using this standard interface potentially allows your
specific authentication scheme to become part of a larger picture in a
JAAS-enabled environment. You've written a LoginModule adapter for your
stuff to be able to use Jackrabbit? Now you can use it everywhere.
Either in the standard java security file, but also as a configuration
of other libraries that hopefully rely on the JAAS standard interfaces
and allow you to provide them with a custom LoginModule.
Sylvain
[1]
http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/spi/LoginModule.html
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
On Wed, 09 Mar 2005 11:13:15 +1100, Ben Alex <be...@acegi.com.au> wrote:
> 1. How does Jackrabbit justify JAAS as the sole security framework, when
> both the JSR 170 specification and implementation reality reflect otherwise?
first of all, jackrabbit is not promoting in any way that JAAS should be used
as the sole security *framework*. i am talking of using the JAAS *api*, namely
LoginModule, Subject & Principal instead of defining
yet-another-authentication-abstraction-api.
it's IMO trivial to implement LoginModule. by using JAAS api's
internally we can keep
jackrabbit's implementation simple and abstract.
> 2. At a conceptual OO level, what is wrong with a security abstraction
> interface that allows people to use the numerous non-JAAS frameworks
> frequently deployed in the real world?
those people would have to write an adapter that implements the
AuthenticationToken interface. i really don't see why this should be
less complicated than writing an adapter that implements LoginModule.
is LoginModule not abstract enough for you?
> 3. How is it enhancing Jackrabbit adoption by alienating all the users
> of home-grown and non-JAAS security frameworks?
why would it alienate those users? again, i am not talking of security
*frameworks*, i am strictly talking of the api that your adapter would
have to implement.
cheers
stefan
>
> Best regards
> Ben
>
Re: JAAS support
Posted by Ben Alex <be...@acegi.com.au>.
Hi David
David Nuescheler wrote:
>>4. Often alternative OSS security frameworks and
>>home-grown approaches cannot easily be made integrate
>>into a JAAS LoginModule
>>
>>
>with respect to authentication in jackrabbit i am not
>creative enough to come up with a usecase
>that cannot easily be wrapped into a JAAS Login
>Module. Do you have any examples in mind?
>
>authorization is certainly a more complicated
>issue.
>
I was referring to the fact some OSS security frameworks take a fairly
sophisticated approach to authentication management, and dropping them
into a LoginModule isn't consistent with their design and architecture.
For example, Acegi Security uses a ThreadLocal to store authentication
details. It offers a range of ways to populate that ThreadLocal, such as
form, basic, digest, anonymous and remember-me authentication. It
authenticates the contents of the ThreadLocal at various times, such as
when an authentication request is first presented and then at each time
a secure object is called. Integration with HttpSession to store the
ThreadLocal contents between HTTP requests is also provided, along with
run-as replacement and automatic propagation of the ThreadLocal contents
from one JVM to another. The entire framework is interface-driven and
wired from a Spring IoC container, so it actively encourages
customisation and extension (something I'd love to see in Jackrabbit).
This type of authentication architecture can be "hammered" to work
within a JAAS LoginModule, with the sacrifice of some functionality,
loss of authentication customisation support, introduction of extra
container-specific configuration (which equals loss of container
portability), and provided that the container collects the credentials
over the appropriate authentication mechanism (basic, digest, form etc)
and presents it to the LoginModule. These trade-offs are actually why,
despite Acegi Security offering this type of integration hook, it is
neither recommended nor do many people rush to use it. Indeed the only
users I've encountered who actually use this integration are EJB users
who are using EJB declarative security. The rest of the community seems
to value the 100% container portability, and richer customisable
services available by not using JAAS.
Despite this, the comparative merit of using Security Framework A over
Security Framework B is not really that important. What matters is that
not all security frameworks in use today are 100% compatible with
LoginModules. Also, Jackrabbit only needs a _minimal_ interface to
integrate with _any_ underlaying security system. I can't see any harm
in offering such an interface, as it is both OO-friendly and helps
develop a stronger Jackrabbit community by encouraging integration into
existing applications and developer preferences.
Best regards
Ben
Re: JAAS support
Posted by David Nuescheler <da...@gmail.com>.
hi ben,
thanks for your comments.
> 1. Not everyone uses JAAS, or even wants to use JAAS
i agree, apparently that seems to be the case.
that's also the main reason why we ended up not
enforcing jaas from a jsr-170 spec perspective.
so from a spec perspective, we should be open enough
i think?
> 4. Often alternative OSS security frameworks and
> home-grown approaches cannot easily be made integrate
> into a JAAS LoginModule
with respect to authentication in jackrabbit i am not
creative enough to come up with a usecase
that cannot easily be wrapped into a JAAS Login
Module. Do you have any examples in mind?
authorization is certainly a more complicated
issue.
regards,
david
Re: JAAS support
Posted by Ben Alex <be...@acegi.com.au>.
First of all, can we at least agree on the following:
1. Not everyone uses JAAS, or even wants to use JAAS
2. Numerous alternative OSS security frameworks exist (eg
http://www.manageability.org/blog/stuff/single-sign-on-in-java/view)
3. Real-world applications see a huge variety of security approaches
including (a) home-grown approaches, (b) alternative OSS frameworks, and
(c) JAAS (probably in that order)
4. Often alternative OSS security frameworks and home-grown approaches
cannot easily be made integrate into a JAAS LoginModule
As someone who administers an OSS security framework project, and have a
good deal of familiarity with JAAS, I know the above four points are
very much the case. I should also mention that I have no ideological
objection to JAAS, as demonstrated by the fact our security framework
offers direct JAAS and application server realm integration.
Stefan Guggisberg wrote:
>what you're saying is if someone wants to adapt Jackrabbit to their own
>authentication scheme, they are going to have to create a
>yet-another-authentication-api adapter/implementation?
>
>
>
The numerous people out there using an OSS security framework, or a
home-grown approach, that would not hesitate or mind implementing the
interface I suggested. After all, it's only a couple of methods and
means they (a) need not replace their entire security infrastructure or
(b) reengineer their security framework to be "JAAS compatible". For the
JAAS users out there, they will be more than effectively served by the
default implementation of the interface that ships with Jackrabbit. They
would not notice nor care about the fact that this extra interface
exists between Jackrabbit and the JAAS layer.
>i can't see anything wrong in jackrabbit using JAAS APIs
>
>
Let me try to answer that. As mentioned above, many people do not want
to use JAAS. A significant proportion of today's applications use
non-JAAS security approaches, and some approaches cannot technically
support JAAS even if they wanted to. Even if JAAS support is
theoretically possible for these frameworks, it's a lot of work making
them operate properly within JAAS - especially compared with
implementing a simple interface such as I proposed in the earlier post.
You also have to ask why these security frameworks have achieved
momentum in the first place, if JAAS was so attractive to all people and
all situations.
>why reinvent our own? you will always have to write an adapater
>if you want to use your own custom authentication scheme.
>i don't a see a benefit in implementing something like
>AuthenticationToken as ben suggested compared to LoginModule.
>
At an OO design level, the golden objective is high cohesion and loose
coupling. The proposed interface represents the subset of authentication
capabilities that Jackrabbit actually needs. Using a simplified
abstraction interface achieves the goal of high cohesion and loose
coupling, whereas hard-coding JAAS references represents low cohesion
(Jackrabbit doesn't need everything JAAS offers) and tight coupling
(non-JAAS approaches that could easily meet Jackrabbit's authentication
requirements cannot be used). Sound OO is reflected by the JSR 170
specification itself which does NOT mandate JAAS.
I hope the above has provided some additional context and the Jackrabbit
community will be supportive of a security abstraction interface. If
not, I suppose I have three questions it would be interesting to receive
some feedback on:
1. How does Jackrabbit justify JAAS as the sole security framework, when
both the JSR 170 specification and implementation reality reflect otherwise?
2. At a conceptual OO level, what is wrong with a security abstraction
interface that allows people to use the numerous non-JAAS frameworks
frequently deployed in the real world?
3. How is it enhancing Jackrabbit adoption by alienating all the users
of home-grown and non-JAAS security frameworks?
Best regards
Ben
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, 8 Mar 2005 08:37:31 -0800, Andy Depue <an...@marathon-man.com> wrote:
> What you're saying is if someone wants to adapt Jackrabbit to their own
> authentication scheme, they are going to have to create a JAAS
> adapter/implementation?
what you're saying is if someone wants to adapt Jackrabbit to their own
authentication scheme, they are going to have to create a
yet-another-authentication-api adapter/implementation?
i can't see anything wrong in jackrabbit using JAAS APIs
why reinvent our own? you will always have to write an adapater
if you want to use your own custom authentication scheme.
i don't a see a benefit in implementing something like
AuthenticationToken as ben suggested compared to LoginModule.
cheers
stefan
> This is doable, no doubt. But Ben's idea has the
> advantage of being simple. There is always a tension and balance between
> "abstract" and "simple" - but what I've seen over the years is that
> developers tend to choose simple over abstract (though not always, of
> course). If I was evaluating Jackrabbit and saw the "AuthenticationToken"
> interface, the cost in implementing it (learning curve + effort + time) would
> be so low that I wouldn't have to give it a second thought. However, if I
> saw that Jackrabbit was tied directly to JAAS, I would have to give it a
> second thought: "is the implementer on the team familiar with JAAS? What
> will his learning curve be, and how much time will it take him to get up to
> speed just enough to create this adapter? How much will the added complexity
> increase testing time (how many more test cases will be necessary to write)?"
> etc...
> Just my 2c. :)
>
> - Andy
>
Re: JAAS support
Posted by Dominique Pfister <do...@day.com>.
Andy Depue wrote:
> On Tuesday 08 March 2005 03:32 am, Dominique Pfister wrote:
>
> What you're saying is if someone wants to adapt Jackrabbit to their own
> authentication scheme, they are going to have to create a JAAS
> adapter/implementation? This is doable, no doubt. But Ben's idea has the
> advantage of being simple. There is always a tension and balance between
> "abstract" and "simple" - but what I've seen over the years is that
> developers tend to choose simple over abstract (though not always, of
> course). If I was evaluating Jackrabbit and saw the "AuthenticationToken"
> interface, the cost in implementing it (learning curve + effort + time) would
> be so low that I wouldn't have to give it a second thought. However, if I
> saw that Jackrabbit was tied directly to JAAS, I would have to give it a
> second thought: "is the implementer on the team familiar with JAAS? What
> will his learning curve be, and how much time will it take him to get up to
> speed just enough to create this adapter? How much will the added complexity
> increase testing time (how many more test cases will be necessary to write)?"
> etc...
Well, I estimate JAAS to be quite a well-known standard nowadays and
every major application server vendor supports it. At the time
authentication and authorization came into place with jackrabbit, a
decision was made to integrate as smoothly as possible into a J2EE
environment. To give an example, this was also the reason for
javax.jcr.XASession to die, because today's resource adapter support
inside application servers makes it obsolete.
> Just my 2c. :)
>
> - Andy
Cheers
Dominique
Re: JAAS support
Posted by Andy Depue <an...@marathon-man.com>.
On Tuesday 08 March 2005 03:32 am, Dominique Pfister wrote:
> Ben Alex wrote:
> > I thought I'd chime in here as I have an interest in both security as
> > well as configuration generally. We're using Spring
> > (www.springframework.org) and Acegi Security
> > (http://acegisecurity.sourceforge.net). We'd like to deploy Jackrabbit
> > into an IoC container so it more easily integrates with the rest of a
> > Spring-based application, and use Acegi Security's ACL and
> > authentication capabilities. I did some refactoring of current code and
> > easily implemented pluggable authentication using an interface as shown
> > (BTW I haven't read the pluggable authentication thread):
> >
> > public interface AuthenticationToken {
> > public void login(String applicationName, Credentials credentials)
> > throws LoginException;
> > public void logout();
> > public String getUserId() throws RepositoryException;
> > public boolean isAnonymous();
> > public boolean isSystem();
> > }
> >
> > This sort of interface allows people to still use JAAS, but also Acegi
> > Security, home-grown solutions (which are very common) etc.
>
> IMO, the concept of JAAS is abstract enough to handle this situation and
> it should be possible to implement a custom LoginModule that will add
> Principal information to the Subject being authenticated in such a way
> that authorization calls made on the Subject will actually be forwarded
> to Acegi.
What you're saying is if someone wants to adapt Jackrabbit to their own
authentication scheme, they are going to have to create a JAAS
adapter/implementation? This is doable, no doubt. But Ben's idea has the
advantage of being simple. There is always a tension and balance between
"abstract" and "simple" - but what I've seen over the years is that
developers tend to choose simple over abstract (though not always, of
course). If I was evaluating Jackrabbit and saw the "AuthenticationToken"
interface, the cost in implementing it (learning curve + effort + time) would
be so low that I wouldn't have to give it a second thought. However, if I
saw that Jackrabbit was tied directly to JAAS, I would have to give it a
second thought: "is the implementer on the team familiar with JAAS? What
will his learning curve be, and how much time will it take him to get up to
speed just enough to create this adapter? How much will the added complexity
increase testing time (how many more test cases will be necessary to write)?"
etc...
Just my 2c. :)
- Andy
Re: JAAS support
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Ben Alex wrote:
> It would be great if Jukka could give us some ideas on what the
> configuration refactoring is moving towards. We'd be hoping it includes
> the elimination of large, application-wide configuration objects; the
> use of getters/setters on classes to set configuration properties and
> collaborating objects; and the use of finer-grained interfaces so that
> smaller pieces of Jackrabbit can be customised, enhanced or replaced (eg
> like the above security example). As I said earlier, we're happy to help
> out with any configuration refactoring (if you would like us to).
I have already converted the Config classes to a more IoC-friendly
format (using constructor dependencies). I have also isolated most of
the XML handling code to the ConfigurationParser class.
I have not attempted to change the fundamental configuration structure
of Jackrabbit. My goal has been to clarify the config package and
provide a clear starting point for future work.
I'll send a more detailed change summary tomorrow and discuss more about
the potential future work related to Jackrabbit configuration. I've
already reached the point where additional config changes would
necessarily touch code also outside the config package, so before
venturing further it would be good to have an open design discussion on
the matter.
BR,
Jukka Zitting
Re: JAAS support
Posted by Dominique Pfister <do...@day.com>.
Ben Alex wrote:
> I thought I'd chime in here as I have an interest in both security as
> well as configuration generally. We're using Spring
> (www.springframework.org) and Acegi Security
> (http://acegisecurity.sourceforge.net). We'd like to deploy Jackrabbit
> into an IoC container so it more easily integrates with the rest of a
> Spring-based application, and use Acegi Security's ACL and
> authentication capabilities. I did some refactoring of current code and
> easily implemented pluggable authentication using an interface as shown
> (BTW I haven't read the pluggable authentication thread):
>
> public interface AuthenticationToken {
> public void login(String applicationName, Credentials credentials)
> throws LoginException;
> public void logout();
> public String getUserId() throws RepositoryException;
> public boolean isAnonymous();
> public boolean isSystem();
> }
>
> This sort of interface allows people to still use JAAS, but also Acegi
> Security, home-grown solutions (which are very common) etc.
IMO, the concept of JAAS is abstract enough to handle this situation and
it should be possible to implement a custom LoginModule that will add
Principal information to the Subject being authenticated in such a way
that authorization calls made on the Subject will actually be forwarded
to Acegi.
Kind regards
Dominique Pfister
Re: JAAS support
Posted by Ben Alex <be...@acegi.com.au>.
Jukka Zitting wrote:
>Hi,
>
>Sylvain:
>
>
>>No, it currently doesn't work. But having pluggable authentication is
>>planned and should come soon. We're waiting for Jukka to finish the
>>ongoing configuration refactoring before adding this new feature.
>>
>>
>
>I'm progressing quite nicely, and should be mostly ready in a day or
>two. :-) I'll send a summary of my config changes when I'm done.
>
>BR,
>
>Jukka Zitting
>
>
>
I thought I'd chime in here as I have an interest in both security as
well as configuration generally. We're using Spring
(www.springframework.org) and Acegi Security
(http://acegisecurity.sourceforge.net). We'd like to deploy Jackrabbit
into an IoC container so it more easily integrates with the rest of a
Spring-based application, and use Acegi Security's ACL and
authentication capabilities. I did some refactoring of current code and
easily implemented pluggable authentication using an interface as shown
(BTW I haven't read the pluggable authentication thread):
public interface AuthenticationToken {
public void login(String applicationName, Credentials credentials)
throws LoginException;
public void logout();
public String getUserId() throws RepositoryException;
public boolean isAnonymous();
public boolean isSystem();
}
This sort of interface allows people to still use JAAS, but also Acegi
Security, home-grown solutions (which are very common) etc.
I am also involved in a separate Spring-based WebDAV server project,
which was started before we became aware Jackrabbit would offer this
capability. It seems the "ongoing configuration refactoring" mentioned
in the above quote might be just what we need. We'd be very happy to
help out with configuration refactoring so that Jackrabbit operated well
in an IoC container, without making any dependency or binding on any
such container. You can read more about what we're trying to achieve and
why we'd like to use Jackrabbit inside on IoC container at
http://www.mail-archive.com/acegiwebdav-developer%40lists.sourceforge.net/msg00006.html.
It would be great if Jukka could give us some ideas on what the
configuration refactoring is moving towards. We'd be hoping it includes
the elimination of large, application-wide configuration objects; the
use of getters/setters on classes to set configuration properties and
collaborating objects; and the use of finer-grained interfaces so that
smaller pieces of Jackrabbit can be customised, enhanced or replaced (eg
like the above security example). As I said earlier, we're happy to help
out with any configuration refactoring (if you would like us to).
Best regards
Ben Alex
Re: JAAS support
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Sylvain:
> No, it currently doesn't work. But having pluggable authentication is
> planned and should come soon. We're waiting for Jukka to finish the
> ongoing configuration refactoring before adding this new feature.
I'm progressing quite nicely, and should be mostly ready in a day or
two. :-) I'll send a summary of my config changes when I'm done.
BR,
Jukka Zitting
Re: JAAS support
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand LEGA wrote:
<snip/>
> This is the point. I tried to use the following code to connect to the
> repository :
>
> (1)
>
> RepositoryConfig config = RepositoryConfig.create(
> configFilePath, repositoryPath ) ;
> RepositoryImpl repository = RepositoryImpl.create(config) ;
> Session session = null ;
> session = repository.login( );
>
> I didn't manage to get it worked. I'm not very used to jackrabbit for
> the moment, so I'm sure that I must have done something wrong.
> The truth is that the following code does work :
>
> (2)
>
> RepositoryConfig config = RepositoryConfig.create(
> configFilePath, repositoryPath ) ;
> RepositoryImpl repository = RepositoryImpl.create(config) ;
> Session session = null ;
> System.setProperty("java.security.auth.login.config",
> "c:\\temp\\jaas.config" ) ;
> session = repository.login( );
>
> So I was under the impression that the support of JAAS was breaking
> the compatibility with older code.
> Could you confirm that the code in (1) still works fine ?
No, it currently doesn't work. But having pluggable authentication is
planned and should come soon. We're waiting for Jukka to finish the
ongoing configuration refactoring before adding this new feature.
BTW, if nobody objects, I volunteer for this change to exercise my
Jackrabbit committer status :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JAAS support
Posted by Bertrand LEGA <le...@yahoo.fr>.
Thanks for your swift answer.
Stefan Guggisberg wrote:
>hi bertrand,
>
>thanks for the patch. unfortunately it doesn't solve the issue and
>it is imo dangerous. setting predefined system properties
>from within an application can cause unpredictable side effects
>and should be avoided.
>
>
>
Yeah, I do agree with that. Especially if others third part components
use these properties.
But I find strange to configure the JAAS authentication at JVM level.
Anyway, you're right.
>please see the thread "Pluggable authentication" for a suggested
>solution.
>
>
>
Oops. I guess I missed that thread.
I have the same concerns as Sylvain. Be able to use JAAS but doesn't
want to modify the JVM settings.
I'm eager to test the release you talked about :)
>btw:
>
>
>
>> * As the current implementation uses the <code>com.sun.security.auth.login.ConfigFile</code>
>> * as the current provider for the login configuration, the application
>>
>>
>
>this is not correct. jackrabbit has no dependencies on
>com.sun.security.auth.login.ConfigFile. all it does is
>
>lc = new LoginContext("name", callbackHandler);
>
>i.e. it uses the installed Configuration, what ever that might be.
>
>
>
Thanks for the details. I'm not proficient with JAAS. So if I did
understantd well, there is no dependency to the installed configuration.
The configuration class I mentionned is just the default one dynamically
loaded.
>> * All that is very boring and breaks compatibility.
>>
>>
>
>
>
This is the point. I tried to use the following code to connect to the
repository :
(1)
RepositoryConfig config = RepositoryConfig.create(
configFilePath, repositoryPath ) ;
RepositoryImpl repository = RepositoryImpl.create(config) ;
Session session = null ;
session = repository.login( );
I didn't manage to get it worked. I'm not very used to jackrabbit for
the moment, so I'm sure that I must have done something wrong.
The truth is that the following code does work :
(2)
RepositoryConfig config = RepositoryConfig.create(
configFilePath, repositoryPath ) ;
RepositoryImpl repository = RepositoryImpl.create(config) ;
Session session = null ;
System.setProperty("java.security.auth.login.config",
"c:\\temp\\jaas.config" ) ;
session = repository.login( );
So I was under the impression that the support of JAAS was breaking the
compatibility with older code.
Could you confirm that the code in (1) still works fine ?
This was more a hack to address that issue (if you confirm it is one).
>sorry, i don't agree. i don't see why this would be 'boring'.
>and what 'compatibilty' does it break?
>
>
>
Well the "boring" comment is very personal. Never mind.
The fact is that the new implementation requires the developper to have
a knowledge of what is JAAS (and how to configure it) even if his
application won't use it.
This is what I meant by boring.
The "pluggable authentication" is IMHO more appropriate. And
furthermore, on its way to the release :)
Regards,
Bertrand.
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
hi bertrand,
thanks for the patch. unfortunately it doesn't solve the issue and
it is imo dangerous. setting predefined system properties
from within an application can cause unpredictable side effects
and should be avoided.
please see the thread "Pluggable authentication" for a suggested
solution.
btw:
> * As the current implementation uses the <code>com.sun.security.auth.login.ConfigFile</code>
> * as the current provider for the login configuration, the application
this is not correct. jackrabbit has no dependencies on
com.sun.security.auth.login.ConfigFile. all it does is
lc = new LoginContext("name", callbackHandler);
i.e. it uses the installed Configuration, what ever that might be.
> * All that is very boring and breaks compatibility.
sorry, i don't agree. i don't see why this would be 'boring'.
and what 'compatibilty' does it break?
cheers
stefan
On Fri, 04 Mar 2005 11:03:03 +0100, Bertrand LEGA
<be...@capgemini.com> wrote:
>
> It seems that my comment was stripped (by Thunderbird ? I don't know )
> So plesae, find below the description of the patch files sent earlier...
>
> Hello,
>
> I added the creation of the jaas config file if not present in the login
> method.
> In fact, the support for JAAS requires to set the env. variable, which
> break compatibility with exiting applications (namely crx).
> I'm not sure the login method is the best place to do so. Please advice,
> if ti should go elsewhere.
>
> So the code creates a jaasgenerated.config in the repository home dir if
> the env. variable (java.security.auth.login.config) is not set, and set
> the variable accordingly. So that applications that didn't use jaas
> don't have to bother about this jaas specific stuff (variable+config file).
>
> A better way would have been to look for a more suitable "configuration
> reader" for jaas, but I didn't had time, and resent to add a dependency
> to JackRabbit.
>
> Let me know, if you find that interesting. I attach the patch just in case.
>
> Regards,
> Bertrand Lega.
>
> This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
>
>
Re: JAAS support
Posted by Bertrand LEGA <be...@capgemini.com>.
It seems that my comment was stripped (by Thunderbird ? I don't know )
So plesae, find below the description of the patch files sent earlier...
Hello,
I added the creation of the jaas config file if not present in the login
method.
In fact, the support for JAAS requires to set the env. variable, which
break compatibility with exiting applications (namely crx).
I'm not sure the login method is the best place to do so. Please advice,
if ti should go elsewhere.
So the code creates a jaasgenerated.config in the repository home dir if
the env. variable (java.security.auth.login.config) is not set, and set
the variable accordingly. So that applications that didn't use jaas
don't have to bother about this jaas specific stuff (variable+config file).
A better way would have been to look for a more suitable "configuration
reader" for jaas, but I didn't had time, and resent to add a dependency
to JackRabbit.
Let me know, if you find that interesting. I attach the patch just in case.
Regards,
Bertrand Lega.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Re: JAAS support
Posted by Stefan Guggisberg <st...@gmail.com>.
hi suhail,
oops, something went wrong in my last commit. i renamed the package
from 'jaas' to 'security' before i committed the changes. but somehow,
mea culpa, the old name got stuck.
i fixed it (rev155394) and i hope that it's ok.
thanks for pointing this out!
cheers
stefan
On Fri, 25 Feb 2005 20:12:31 +0100, Suhail M. Ahmed <il...@mac.com> wrote:
> Thanks Stefan,
>
> I got the svn update. The SimpleLoginModule works ! I did have to make
> a few changes though, the codebase/config was still referring to
> org.apache.jackrabbit.core.security which I had to change to
> *.core.jaas. I'll head back into my rabbit hole now :)
>
> cheers
> Suhail
>
> On Feb 25, 2005, at 6:15 PM, Stefan Guggisberg wrote:
>
> > folks,
> > i committed a first implementation of generic JAAS support
> > (rev155344). jackrabbit is now making use of standard JAAS mechanisms
> > (-> configurable LoginModules) to authenticate users. the relevant
> > code
> > is in RepositoryImpl.login() and in the code in the 'security' package.
> >
> > there's a SimpleLoginModule and a SimpleAccessManager in the
> > security package. those don't do anything right now and are intended
> > as fallbacks.
> >
> > in case you run into a java.lang.SecurityException (LoginConfig not
> > found)
> > when you start jackrabbit you have to set the system property
> > java.security.auth.login.config with the path to your JAAS config
> > file.
> > i added a sample config (src/conf/jaas.config). this config specifies
> > the SimpleLoginModule for the "Jackrabbit" application.
> >
> > now it should be very easy to use LDAP-based authorization with
> > jackrabbit.
> >
> > next steps:
> > - make the AccessManager and name of the config entry
> > configurable (in repository.xml)
> > - provide very simple username/password authorization
> > as sample/fallback.
> >
> > cheers
> > stefan
>
>
Re: JAAS support
Posted by "Suhail M. Ahmed" <il...@mac.com>.
Thanks Stefan,
I got the svn update. The SimpleLoginModule works ! I did have to make
a few changes though, the codebase/config was still referring to
org.apache.jackrabbit.core.security which I had to change to
*.core.jaas. I'll head back into my rabbit hole now :)
cheers
Suhail
On Feb 25, 2005, at 6:15 PM, Stefan Guggisberg wrote:
> folks,
> i committed a first implementation of generic JAAS support
> (rev155344). jackrabbit is now making use of standard JAAS mechanisms
> (-> configurable LoginModules) to authenticate users. the relevant
> code
> is in RepositoryImpl.login() and in the code in the 'security' package.
>
> there's a SimpleLoginModule and a SimpleAccessManager in the
> security package. those don't do anything right now and are intended
> as fallbacks.
>
> in case you run into a java.lang.SecurityException (LoginConfig not
> found)
> when you start jackrabbit you have to set the system property
> java.security.auth.login.config with the path to your JAAS config
> file.
> i added a sample config (src/conf/jaas.config). this config specifies
> the SimpleLoginModule for the "Jackrabbit" application.
>
> now it should be very easy to use LDAP-based authorization with
> jackrabbit.
>
> next steps:
> - make the AccessManager and name of the config entry
> configurable (in repository.xml)
> - provide very simple username/password authorization
> as sample/fallback.
>
> cheers
> stefan