Hi Chris,
With regards to the Authn filters in the web.xml file, I noticed 2 things when
FeSL is enabled:
1) The following 5 filters are still in there (should be removed):
<filter>
<filter-name>SetupFilter</filter-name>
<filter-class>org.fcrepo.server.security.servletfilters.FilterSetup</filter-class>
</filter>
<filter>
<filter-name>XmlUserfileFilter</filter-name>
<filter-class>org.fcrepo.server.security.servletfilters.xmluserfile.FilterXmlUserfile</filter-class>
</filter>
<filter>
<filter-name>RestApiAuthnFilter</filter-name>
<filter-class>org.fcrepo.server.security.servletfilters.FilterRestApiAuthn</filter-class>
</filter>
<filter>
<filter-name>EnforceAuthnFilter</filter-name>
<filter-class>org.fcrepo.server.security.servletfilters.FilterEnforceAuthn</filter-class>
</filter>
<filter>
<filter-name>FinalizeFilter</filter-name>
<filter-class>org.fcrepo.server.security.servletfilters.FilterFinalize</filter-class>
</filter>
2) There are 2 filter mappings for the PEPFilter to the UserServlet, one based
on ServletName and the other on url pattern. I think we just need 1 right? and
the one based on servlet name would be more ideal?
<filter-mapping>
<filter-name>PEPFilter</filter-name>
<servlet-name>UserServlet</servlet-name>
</filter-mapping>
<filter-mapping>
<filter-name>PEPFilter</filter-name>
<url-pattern>/user</url-pattern>
</filter-mapping>
Thanks,
Nish
________________________________
Nishen Naidoo
IT Projects Developer
Library IT
MACQUARIE UNIVERSITY NSW 2109
E-Mail:
[email protected]<https://owa.lib.mq.edu.au/owa/redir.aspx?C=41cbe96f92f5488a9816f2b2e77a45ff&smime=8.1.348.0&URL=mailto:[email protected]>
Phone: +61 2 98506553
Mobile: +61 4 30006783
Fax: +61 2 98507912
http://www.library.mq.edu.au/<https://owa.lib.mq.edu.au/owa/redir.aspx?C=41cbe96f92f5488a9816f2b2e77a45ff&smime=8.1.348.0&URL=http:%2F%2Fwww.library.mq.edu.au%2F>
CRICOS Provider No 00002J
This message is intended for the addressee named and may contain confidential
information. If you are not the intended recipient, please delete it and notify
the sender. Views expressed in this message are those of the individual sender,
and are not necessarily the views of Macquarie University Library or Macquarie
University.
Please consider the environment before printing this email.
________________________________
From: [email protected] [[email protected]] On Behalf Of Chris Wilper
[[email protected]]
Sent: Saturday, 20 March 2010 5:06 AM
To: Nishen Naidoo
Cc: Chi Nguyen; FC Developers List
Subject: Re: [Fedora-commons-developers] Deprecating old AuthN in favor of FESL
AuthN?
Hi Nish,
I agree, getting more eyes on the AuthN part would be good too, before
making it the default option. While they're both in the experimental
phase, I think having the option to choose to enable either in the
installer would help get more eyes on the AuthN part (both developers
and potential users). To that end, I've created:
http://fedora-commons.org/jira/browse/FCREPO-671
This is now done in trunk, so at least it will be an option for 3.4.
I'm planning on doing a 3.3.1 (bugfix) release soon, and think it
would be a good idea to backport this option so it can be included in
that release as well, again, to get more eyes on it. Ultimately, to
build up the confidence so we can enable FeSL's AuthN as the default
option and get rid of the legacy AuthN servlet filters.
- Chris
On Fri, Mar 12, 2010 at 9:15 PM, Nishen Naidoo <[email protected]> wrote:
> Hi Chris,
>
> I don't see any reason why we can't get this out there. It will be good to
> get some real world feedback for improvements or issues that may arise.
>
> I also think it might solve a few peoples issues with dealing with LDAP and
> will work well with AD authentication.
>
> The authn module was developed independantly of the authz and I tried to
> make it work with the current fedora authz and I believe it does.
>
> So in my opinion it should be good to go. It would be nice if we can get
> people to switch to it before a 3.4 release and try it out before
> deprecating (or dropping) the current system... just as an extra
> precaution...
>
> Thanks,
> Nish
>
>
> ________________________________
>
> Nishen Naidoo
> IT Projects Developer
> Library IT
> MACQUARIE UNIVERSITY NSW 2109
>
> E-Mail: [email protected]
> Phone: +61 2 98506553
> Mobile: +61 4 30006783
> Fax: +61 2 98507912
> http://www.library.mq.edu.au/
>
> CRICOS Provider No 00002J
>
> This message is intended for the addressee named and may contain
> confidential information. If you are not the intended recipient, please
> delete it and notify the sender. Views expressed in this message are those
> of the individual sender, and are not necessarily the views of Macquarie
> University Library or Macquarie University.
>
> Please consider the environment before printing this email.
>
>
>
> ________________________________
> From: [email protected] [[email protected]] On Behalf Of Chris Wilper
> [[email protected]]
> Sent: Saturday, 13 March 2010 4:06 AM
> To: Nishen Naidoo
> Cc: Chi Nguyen; FC Developers List
> Subject: Re: [Fedora-commons-developers] Deprecating old AuthN in favor of
> FESL AuthN?
>
> Ahh, thanks for the clarification, Nishen...I missed the fact that the
> other attributes (not just roles) were populated as well within the
> populateFedoraRoles method. I've changed the name to
> populateFedoraAttributes.
>
> Back to my original question: Can we deprecate (or drop!) the old
> AuthN code in favor of FESL's AuthN for 3.4? I think the answer is
> yes because it would still work with the old AuthZ:
>
> http://fedora-commons.org/jira/browse/FCREPO-664
>
> As far as "what we can tell people today re:LDAP", I think the answer
> is that they can follow these instructions to post-configure FeSL's
> AuthN, but due to FCREPO-615, they'd need to require AuthN on the
> entire REST api in order to get authentication on the write-oriented
> part of it:
>
> http://fedora-commons.org/jira/browse/FCREPO-615
>
> - Chris
>
> On Fri, Mar 12, 2010 at 7:43 AM, Nishen Naidoo <[email protected]>
> wrote:
>> Hi Chris,
>>
>> Reading the docs and looking at AuthFilterJAAS, it looks like the
>> multi-valued "fedoraRole" attribute is the only one that's passed down
>> the chain via FEDORA_AUX_SUBJECT_ATTRIBUTES. While it is possible via
>> AuthFilterJAAS's configuration to map other LDAP attributes to
>> fedoraRole (and thus have their *values* passed down the chain, it is
>> not possible to pass the original, LDAP-defined name-value pairs down.
>>
>> Is this correct? If so, why? It seems simple enough to provide all
>> the attribute name-value pairs here (so they could be used as subject
>> attributes during AuthZ), so I think I must be missing something.
>> I had to go through the code again to remember what was going on, but all
>> attributes that are selected are in fact passed along to the
>> FEDORA_AUX_SUBJECT_ATTRIBUTES, not just fedoraRole. However, you need to
>> speciy which attributes to collect and pass onto the principal in
>> the jaas.conf file.
>>
>> For example:
>>
>> fedora-auth
>> {
>> org.fcrepo.server.security.jaas.auth.module.LdapModule sufficient
>> host.url="ldap://dev01.muradora.org";
>> auth.type="simple"
>> bind.mode="bind"
>> bind.filter="uid={0},ou=people,dc=muradora,dc=org"
>> attrs.fetch="cn,sn,mail,displayName,carLicense,eduPersonEntitlement"
>> debug=true;
>>
>> org.fcrepo.server.security.jaas.auth.module.XmlUsersFileModule
>> sufficient
>> debug=true;
>> };
>>
>> If you add the attrs.fetch line to your jaas configuration, it will
>> specify
>> the list of attributes to pull from the LDAP server and add to the
>> FEDORA_AUX_SUBJECT_ATTRIBUTES map. So in the above example, cn, sn, email
>> etc. will also be attributes accessable from the
>> FEDORA_AUX_SUBJECT_ATTRIBUTES provided they have values in the LDAP
>> directory.
>>
>> Thanks,
>> Nish
>>
>> ________________________________
>>
>> Nishen Naidoo
>> IT Projects Developer
>> Library IT
>> MACQUARIE UNIVERSITY NSW 2109
>>
>> E-Mail: [email protected]
>> Phone: +61 2 98506553
>> Mobile: +61 4 30006783
>> Fax: +61 2 98507912
>> http://www.library.mq.edu.au/
>>
>> CRICOS Provider No 00002J
>>
>> This message is intended for the addressee named and may contain
>> confidential information. If you are not the intended recipient, please
>> delete it and notify the sender. Views expressed in this message are those
>> of the individual sender, and are not necessarily the views of Macquarie
>> University Library or Macquarie University.
>>
>> Please consider the environment before printing this email.
>>
>>
>>
>> ________________________________
>> From: Chris Wilper [[email protected]]
>> Sent: Thursday, 11 March 2010 10:09 PM
>> To: Chi Nguyen
>> Cc: FC Developers List
>> Subject: Re: [Fedora-commons-developers] Deprecating old AuthN in favor of
>> FESL AuthN?
>>
>> Thanks Chi,
>>
>> I've successfully tested this with the following steps against
>> OpenLDAP on Ubuntu:
>>
>> 1) installed from fedora trunk with FeSL off, legacy XACML on
>> 2) modified jaas.conf to use cascading authN (ldap direct bind
>> sufficient, xml user file sufficient)
>> 3) modified web.xml as instructed in the doc, to authenticate for
>> everything for simplicity
>>
>> Going against UserServlet (great idea for sanity checking btw), I was
>> able to authenticate and see the attributes of the fedoraAdmin user
>> (defined in the xml user file), and my other test user (defined only
>> in LDAP). I also verified that fedoraAdmin was allowed to do admin
>> things, and my other test user was not (via legacy XACML enforcement).
>>
>> Reading the docs and looking at AuthFilterJAAS, it looks like the
>> multi-valued "fedoraRole" attribute is the only one that's passed down
>> the chain via FEDORA_AUX_SUBJECT_ATTRIBUTES. While it is possible via
>> AuthFilterJAAS's configuration to map other LDAP attributes to
>> fedoraRole (and thus have their *values* passed down the chain, it is
>> not possible to pass the original, LDAP-defined name-value pairs down.
>>
>> Is this correct? If so, why? It seems simple enough to provide all
>> the attribute name-value pairs here (so they could be used as subject
>> attributes during AuthZ), so I think I must be missing something.
>>
>> Thanks,
>> Chris
>>
>> On Wed, Mar 10, 2010 at 6:42 PM, Chi Nguyen <[email protected]> wrote:
>>> That is certainly possible (and I think would be most useful), though you
>>> would need to install the jaas-module after installing Fedora without
>>> enabling the FeSL module. Unfortunately, there's no option at the moment
>>> with the Fedora install to install just the AuthN bit without the Authz,
>>> so
>>> I'm attaching the doc written by Nish for getting the AuthN module
>>> support
>>> over a vanilla Fedora install.
>>> -chi
>>>
>>>
>>> On Thu, Mar 11, 2010 at 5:30 AM, Chris Wilper <[email protected]>
>>> wrote:
>>>>
>>>> Are we in a position to be able to do this for 3.4? I know there's
>>>> some work to be done on the AuthZ side before we can fully replace the
>>>> old Authorization module, but I'm less clear on the AuthN side of
>>>> things.
>>>>
>>>> http://fedora-commons.org/confluence/display/FCR30/FeSL+Authentication
>>>>
>>>> The old AuthN's Xml user file-based AuthN is working fine out of the
>>>> box today, but it seems like people are constantly running into
>>>> trouble getting LDAP authentication to work with it.
>>>>
>>>> So, actually, a couple questions:
>>>>
>>>> 1) What potential gotchas would there be to swapping in FESL's AuthN
>>>> for 3.4 in place of the old AuthN code?
>>>>
>>>> 2) In the meantime, what can we tell people like Jens (below) who are
>>>> struggling with LDAP integration today? (Is it possible to use FESL's
>>>> AuthN without it's AuthZ, and what's the set of instructions to do
>>>> that for 3.3?)
>>>>
>>>> - Chris
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Jens Pelzetter <[email protected]>
>>>> Date: 2010/3/10
>>>> Subject: [Fedora-commons-users] Need help with LDAP setup
>>>> To: Fedora Mailing List <[email protected]>
>>>>
>>>>
>>>> Hello everybody,
>>>>
>>>> I need help setting up Fedora 3.3 to use an LDAP repository for
>>>> authentication and authorization.
>>>>
>>>> My problem is: It looks like the user is correctly found in LDAP
>>>> repository. The groups also read successfully from the LDAP, as far as I
>>>> can tell from the logs. But after this, there is an error in the log:
>>>>
>>>> ERROR 2010-03-10 14:09:23.838 [http-8080-1] (BaseCaching) general
>>>> authenticate() failure
>>>> authenticate() failure
>>>> ERROR 2010-03-10 14:09:23.838 [http-8080-1] (BaseCaching)
>>>> java.lang.Exception
>>>> ERROR 2010-03-10 14:09:23.839 [http-8080-1] (BaseCaching)
>>>>
>>>> Also, I found an exception in the logs of the Tomcat which is running
>>>> our Fedora installation:
>>>>
>>>>
>>>> java.lang.Exception
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.ExtendedHttpServletRequestWrapper.setAuthenticated(ExtendedHttpServletRequestWrapper.java:79)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.BaseCaching.authenticate(BaseCaching.java:274)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.BaseContributing.doThisSubclass(BaseContributing.java:224)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:211)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:234)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:234)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>> at
>>>>
>>>>
>>>>
>>>> fedora.server.security.servletfilters.FilterSetup.doFilter(FilterSetup.java:234)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>>> at
>>>>
>>>>
>>>>
>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
>>>> at
>>>>
>>>>
>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
>>>> at org.apache.coyote.http11.Http11Protocol
>>>> $Http11ConnectionHandler.process(Http11Protocol.java:583)
>>>> at org.apache.tomcat.util.net.JIoEndpoint
>>>> $Worker.run(JIoEndpoint.java:454)
>>>> at java.lang.Thread.run(Thread.java:619)
>>>>
>>>> Has anybody an idea the problem is here, and how to fix it?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Jens Pelzetter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Fedora-commons-users mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Fedora-commons-developers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Fedora-commons-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
