Thanks for catching the typo. I updated the wiki.

I am guessing that the version of spring that "spring-security-ldap"
depends on is different than what other dependencies in the pom use. (You
could check this by running mvn dependency:tree from the command prompt)
and so because it doesn't find them, it needs to exclusively bring them
down. Excluding them manually is the way to prevent that.

> -----Original Message-----
> From: Paul B. Henson [mailto:hen...@csupomona.edu]
> Sent: Thursday, August 1, 2013 8:47 PM
> To: cas-user@lists.jasig.org
> Subject: Re: [cas-user] service manager application authorization via
LDAP
> 
> On Thu, Aug 01, 2013 at 07:21:54PM -0700, Paul B. Henson wrote:
> 
> > After beating my head against the wall for a while, I figured out that
> > somehow adding this dependency resulted in multiple versions of some
> > jars ending up in the war maven created:
> 
> I managed to work around this by adding explicit exclusions to pom.xml:
> 
>                 <dependency>
>                         <groupId>org.springframework.security</groupId>
>                         <artifactId>spring-security-ldap</artifactId>
>                         <version>3.1.1.RELEASE</version>
>                         <exclusions>
>                                 <exclusion>
>
<groupId>org.springframework</groupId>
>
<artifactId>spring-aop</artifactId>
>                                 </exclusion>
>                                 <exclusion>
>
<groupId>org.springframework</groupId>
>
<artifactId>spring-tx</artifactId>
>                                 </exclusion>
>                                 <exclusion>
>
<groupId>org.springframework</groupId>
>
<artifactId>spring-beans</artifactId>
>                                 </exclusion>
>                                 <exclusion>
>
<groupId>org.springframework</groupId>
>
<artifactId>spring-context</artifactId>
>                                 </exclusion>
>                                 <exclusion>
>
<groupId>org.springframework</groupId>
>
<artifactId>spring-core</artifactId>
>                                 </exclusion>
>                         </exclusions>
>                 </dependency>
> 
> Is that really what needed to be done? Seems awfully manual as a
process;
> scan war for duplicate jars and go list them one by one?
> 
> 
> Then I had the error:
> 
> Error creating bean with name 'casAuthenticationProvider' defined in
> ServletContext resource [/WEB-I
> NF/spring-configuration/securityContext.xml]: Cannot resolve reference
to
> bean 'userDetailsService' while  setting bean property
'userDetailsService';
> nested exception is org.springframework.beans.factory.NoSuch
> BeanDefinitionException: No bean named 'userDetailsService' is defined
> 
> Looks like there's a typo on the configuration wiki page? The example
config
> is listed as
>       sec:ldap-user-service id="userService"
> evidentally it should be
>       sec:ldap-user-service id="userDetailsService"
> 
> 
> Well, now I'm getting "Access Denied", so I guess the job for tomorrow
is to
> figure out how to map an ldap group into the role the service management
> app wants to see to authorize access...
> 
> 
> --
> Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
> 
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> mmoay...@unicon.net To unsubscribe, change settings or access archives,
> see http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to