views:

2745

answers:

5

I'm some what lost as to why spring isn't enforcing the @Secured("ROLE_USER") on my service interface. My controllers are established using annotations.

An example of my service Interface

public interface MyServiceManager {

    @Secured("ROLE_USER")
    public void delete(int cid);

    @RolesAllowed({"ROLE_USER"})
    public Contact getContact(int contactId);
}

my security-context:

<global-method-security   secured-annotations="enabled" jsr250-annotations="enabled">
</global-method-security>

<http auto-config="true" >
 <intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR" />
 <intercept-url pattern="/addcontact**" access="IS_AUTHENTICATED_REMEMBERED" />
 <intercept-url pattern="/**" access="IS_AUTHENTICATED_ANONYMOUSLY" />

 <concurrent-session-control max-sessions="1"
  exception-if-maximum-exceeded="true"/>
 <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?login_error=1"/>
 <logout logout-success-url="/welcome.do" logout-url="/logout"/>
</http>
    <authentication-provider>
    <password-encoder hash="md5"/>
    <user-service>
        <user name="rod" password="a564de63c2d0da68cf47586ee05984d7" authorities="ROLE_SUPERVISOR, ROLE_USER, ROLE_TELLER" />
    </user-service>
</authentication-provider>
+2  A: 

Do you have the statement

<global-method-security   secured-annotations="enabled" jsr250-annotations="enabled" />

in the same configuration file as the one you defined the MyServiceManager bean? I had the same problem until I turned on debug for org.springframework, and noticed that spring security was only applied on the same file as the ones where global-method-security was defined in.

Kent Lai
I'm importing the security-context.xml and datasource-context.xml into the applicationContext.xml. Moving up <context:annotation-config /> seemed to fix the url path security role issue. but not the method security issue.
oneBelizean
A: 

Try putting the annotations on the implementation class instead of the interface and see if that works. I ended up doing that on a recent project because I was also using the @Transactional attribute on my service layer, and the Spring docs recommend putting those on the class and not the interface. I don't know if the same issue might apply to @Secured, but I wanted to keep the annotations in the same place. See the Spring Docs

Regarding Kent Lai's answer...that is a good idea...make sure that your security config file is actually being included by Spring.

Jeff Olson
+1  A: 

After doing more research on this problem I came to the following conclusion/solution. I'm not sure if it's 100% correct..but it works.

I put all of my configuration in the dispatcher-servlet.xml file. So instead of having a disptacher-servlet.xml and application-context.xml. The dispatcher-servlet.xml is loaded by the application (contextConfigLocation). Within the dispatcher-servlet.xml I import my security-context.xml and datasource-context.xml. Afer that, everything works.

oneBelizean
+2  A: 

I had this same problem. Using the information from Kent Lai's reply here, I was able to fix it.

I put the <global-method-security> element in my app-servlet.xml but kept the security definitions separate in security.xml, where web.xml has contextConfigLocation for app-servlet.xml and security.xml.

Works like a charm now!

Joe Skora
The way I understood this it's a bit redundant to define your app-servlet.xml file as part of the contextConfigLocation. If you use DispatcherServlet it will load your servletname-servlet.xml which inherits the WebApplicationContext. In this case it seems to me that your beans will first be created once in your WebApplicationContext by your ContextLoader and then overridden with the same definitions another time by your DispatcherServlet.
Sam
Wow, I'll have to check that. Thanks!
Joe Skora
A: 

can you paste the code how did u do that ?

javaer