Як створити власні методи для використання у весняних анотаціях мови виразів безпеки

Я хотів би створити клас, який додає власні методи для використання у весняній мові виразів безпеки для авторизації на основі методів за допомогою анотацій.

Наприклад, я хотів би створити власний метод, такий як 'customMethodReturningBoolean', який буде використовуватися якось так:

  @PreAuthorize("customMethodReturningBoolean()")
  public void myMethodToSecure() { 
    // whatever
  }

Моє питання таке. Якщо це можливо, який клас слід підкласувати для створення власних методів, як би я налаштував його у весняних файлах конфігурації xml і прийшов, щоб хтось дав мені приклад користувацького методу, використовуваного таким чином?

Вам потрібно буде підклас двох класів.

Спочатку встановіть новий обробник виразів методу

<global-method-security>
  <expression-handler ref="myMethodSecurityExpressionHandler"/>
</global-method-security>

myMethodSecurityExpressionHandlerбуде підкласом, DefaultMethodSecurityExpressionHandlerякий замінює createEvaluationContext(), встановлюючи підклас MethodSecurityExpressionRootна MethodSecurityEvaluationContext.

Наприклад:

@Override
public EvaluationContext createEvaluationContext(Authentication auth, MethodInvocation mi) {
    MethodSecurityEvaluationContext ctx = new MethodSecurityEvaluationContext(auth, mi, parameterNameDiscoverer);
    MethodSecurityExpressionRoot root = new MyMethodSecurityExpressionRoot(auth);
    root.setTrustResolver(trustResolver);
    root.setPermissionEvaluator(permissionEvaluator);
    root.setRoleHierarchy(roleHierarchy);
    ctx.setRootObject(root);

    return ctx;
}

Жодна із згаданих методик вже не буде працювати. Здається, що Spring пройшов багато часу, щоб не дати користувачам замінити SecurityExpressionRoot.

EDIT 11/19/14 Налаштування Spring для використання анотацій безпеки:

<beans ... xmlns:sec="http://www.springframework.org/schema/security" ... >
...
<sec:global-method-security pre-post-annotations="enabled" />

Створіть такий боб:

@Component("mySecurityService")
public class MySecurityService {
    public boolean hasPermission(String key) {
        return true;
    }
}

Тоді зробіть щось подібне у своєму jsp:

<sec:authorize access="@mySecurityService.hasPermission('special')">
    <input type="button" value="Special Button" />
</sec:authorize>

Або анотуйте метод:

@PreAuthorize("@mySecurityService.hasPermission('special')")
public void doSpecialStuff() { ... }

Крім того, ви можете використовувати Spring Expression Language у своїх @PreAuthorizeанотаціях для доступу до поточної автентифікації, а також аргументів методу.

Наприклад:

@Component("mySecurityService")
public class MySecurityService {
    public boolean hasPermission(Authentication authentication, String foo) { ... }
}

Потім оновіть свій, @PreAuthorizeщоб він відповідав підпису нового методу:

@PreAuthorize("@mySecurityService.hasPermission(authentication, #foo)")
public void doSpecialStuff(String foo) { ... }

Дякую ericacm , але це не працює з кількох причин:

• Властивості DefaultMethodSecurityExpressionHandler є приватними (клуби видимості відображення небажані)
• Принаймні , в моєму Eclipse, я не можу вирішити MethodSecurityEvaluationContext об'єкт

Відмінності полягають у тому, що ми викликаємо існуючий метод createEvaluationContext, а потім додаємо власний кореневий об’єкт. Нарешті, я щойно повернув тип об’єкта StandardEvaluationContext, оскільки MethodSecurityEvaluationContext не вирішить проблему в компіляторі (вони обидва з одного інтерфейсу). Це код, який я зараз маю на виробництві.

Зробіть MethodSecurityExpressionHandler використовувати наш власний корінь:

public class CustomMethodSecurityExpressionHandler extends DefaultMethodSecurityExpressionHandler  {

    // parent constructor
    public CustomMethodSecurityExpressionHandler() {
        super();
    }

    /**
     * Custom override to use {@link CustomSecurityExpressionRoot}
     * 
     * Uses a {@link MethodSecurityEvaluationContext} as the <tt>EvaluationContext</tt> implementation and
     * configures it with a {@link MethodSecurityExpressionRoot} instance as the expression root object.
     */
    @Override
    public EvaluationContext createEvaluationContext(Authentication auth, MethodInvocation mi) {
        // due to private methods, call original method, then override it's root with ours
        StandardEvaluationContext ctx = (StandardEvaluationContext) super.createEvaluationContext(auth, mi);
        ctx.setRootObject( new CustomSecurityExpressionRoot(auth) );
        return ctx;
    }
}

Це замінює root за замовчуванням, розширюючи SecurityExpressionRoot . Тут я перейменував hasRole на hasEntitlement:

public class CustomSecurityExpressionRoot extends SecurityExpressionRoot  {

    // parent constructor
    public CustomSecurityExpressionRoot(Authentication a) {
        super(a);
    }

    /**
     * Pass through to hasRole preserving Entitlement method naming convention
     * @param expression
     * @return boolean
     */
    public boolean hasEntitlement(String expression) {
        return hasRole(expression);
    }

}

Нарешті оновіть securityContext.xml (і переконайтеся, що на нього посилається ваш applcationContext.xml):

<!-- setup method level security using annotations -->
<security:global-method-security
        jsr250-annotations="disabled"
        secured-annotations="disabled"
        pre-post-annotations="enabled">
    <security:expression-handler ref="expressionHandler"/>
</security:global-method-security>

<!--<bean id="expressionHandler" class="org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler">-->
<bean id="expressionHandler" class="com.yourSite.security.CustomMethodSecurityExpressionHandler" />

Примітка. Анотація @Secured не прийме цю заміну, оскільки вона проходить через інший обробник перевірки. Отже, у наведеному вище xml я відключив їх, щоб уникнути подальшої плутанини.