There is currently no timeline for a version 3, but this space represents any brainstorming efforts that the community wishes to address that may be major feature enhancements that can't be backwards compatible. Typically discussions from the dev list resulting in some form of consensus will probably make it into this page. Actionable items will go into Jira, potentially referencing this page for clarity.

  • (I know this isn't a feature but its equally is not more important) Deeper and more accessible documentation and how-tos.
  • management system for long lived hashes
  • token/ticket system
  • more generalized way to handle unauthorized exceptions
  • lower level crypto toolkit to facilitate customizations
  • unauthorizedUrl per path filter

A thread has been started on the mailing list to discuss with the users:

https://lists.apache.org/thread.html/r965efe7a90a68091936322f426a9aebe0a1b27ee449a8f2feac5d433%40%3Cdev.shiro.apache.org%3E

Remove the usage of the word Principal

Unfortunately, the word 'principal' has different meanings depending on your background in security and what security projects or products you might have used. Shiro has participated in this mix by defining Principal to mean any identifying attribute. Instead of perpetuating this potentially-confusing term further (within Shiro at least), we might want to drop the word 'principal' in favor of 'attribute', since Shiro only ever refers to principals as identifying attributes.

For example, this would imply renaming (or more likely, deprecating) PrincipalCollection to be AttributeCollection. Or even more likely AttributeMap (see Subject PrincipalCollection section below).

This would imply things like:

AuthenticationToken<I,C> {

    I getIdentifier();

    C getCredentials();    
}

and

public interface Subject {

    ...

    //instead of getPrincipal():
    // the application's primary identifier (e.g. username or email address or db primary key):
    Serializable getId();

    //instead of getPrincipals():
    AttributeMap getAttributes();

}

Rename AuthenticationInfo to Account

The existing AuthenticationInfo name is less intuitive and is essentially the same thing.

Realm refactoring

Most Realms differ little in their implementations - mostly by the protocols they use. Create a 'DefaultRealm' implementation (or something similar) that allows pluggable AccountResolver and AuthorizationResolver interfaces that abstract away interaction with the data stores and the rest of the internal Realm logic (e.g. authc and authz caching, etc) can be shared by most Realm implementation.

Refactor shiro-core and it's modules (consolidate)

Merge some modules, split some? e.g. shiro-authc, shiro-authz

Move events to a standard API

Move EventBus to JDK Flow API.

Implementation can be CDI, Sprint, etc.

Subject PrincipalCollection

Convert this to be a sub-interface of Map with additional per-Realm utility methods.

See the PrincipalMap concept for ideas (experimental, not referenced in Shiro 1.x at the moment).

Maybe rename this to 'attributes'? i.e. subject.getAttributes()?

Component Names

Change classes named FooDAO to FooStore instead.

Authorization ANTLR Grammar

Ideally, we can have a single annotation:

@Secured("authz expression here")
public void someMethod(){...}

Where the 'authz expression here' is authorization assertion statement backed by an ANTLR lexer/parser, for example:

@Secured("(role(admin) || role(developer)) || perm(account:12345:open)")

This would translate the expression into the relevant hasRole/isPermitted calls.

AuthorizationRequest/Response

Employing the same grammar as mentioned above, instead of multiple subject.isPermitted/hasRole calls, the same thing could be achieved with an AuthorizationRequest/Response scheme. For example:

AuthorizationRequest request = //create request w/ expression
AuthorizationResponse response = subject.authorize(authorizationRequest);
if (response.isAuthorized()) {
...
} else {
...
}

Reinforce customization via OO Delegation (composition over inheritance)

  • Any of the features provided by PathMatchingFilter would be provided for any configured filter via a proxy mechanism. The proxy would likely support the PathMatchingFilter features, setting request attributes as necessary for the wrapped filter to react to. This eliminates the need to subclass PathMatchingFilter to utilize these features.
  • The same principal would be probably be applied for realms. A DefaultRealm could be created that delegates to an AuthenticationInfoAccessor and AuthorizationInfoAccessor (or whatever we want to call them) that performs the same behavior as AuthenticatingRealm#doGetAuthenticationInfo and AuthorizingRealm#doGetAuthorizationInfo. The end result is no more subclassing realms for 95% of use cases, and instead providing accessors.

Multi-Stage Authentication via request/response

In applications that need to authenticate via multiple mechanisms (e.g. multi-factor authentication), a Request/Response protocol for login would probably be easier to use to support such workflows. For example:

LoginRequest request = //create login request
LoginResponse response = subject.login(request);
if (!response.isComplete()) {
    LoginRequest secondRequest = response.nextRequest();
    //populate w/ data for 2nd phase
   response = subject.login(secondRequest);
}
if (response.hasException()) {
    throw response.getException();
}
...

Additionally probably change the Authenticator signature to be as follows:

AuthenticationResult authenticate(AuthenticationRequest) throws AuthenticationException;

Captcha Support

Captcha support would assist in human being verification (during login, during form submission, etc).

Configuration per filter instance and no path matching


SHIRO-256 is opened for this and Tynamo.org already has an implementation for it. This would both simplify the filter logic and result in better performance.

Web module repackaging.

The Web module is largely Servlet-specific at the moment. As such, its packaging should reflect this, in the same way that all other support modules are named, e.g.
module name: shiro-servlet
package base: org.apache.shiro.servlet.*

OAuth 2.0 Support

(copied from: https://github.com/apache/shiro/pull/46#issuecomment-636014863)

IMHO, OAuth2 (and OIDC) is a must-have for 2.0. I think the openid4j project is dead though.
But... it's a good start of where the bits need to be plugged in.

I've been thinking about options in the back of my head for a while now. And I need to start writing them down (both code and on the dev list). I'll add a note here for now, because i'm thinking about it.

There are a couple of main use cases we need to target (and even more nice-to-haves)

* Resource Server support - Shiro has Bearer Token support for this, which is half the battle, we could add "opaque" access token validation as a Realm.
  I worry about generic JWT access token validation as each vendor recommends different validation (as JWTs are NOT part of the OAuth spec), but other libraries have support, so...

* OAuth 2.0 Auth Code Flow - there will be a heavy dependency on the servlet (or similar) specs for this

* OIDC support (similar to previous)

All of these options depend on an HTTP client component which Shiro doesn't have. It's easy enough to add, but we may need to expose some of the underlying bits of said client, to allow for a whole host of client-to-server communication. (timeouts, HTTP headers for firewall negation, proxies, etc).

Mostly just quick thoughts, I need to dig into this again

Maybe just use MP OIDCConnect and integrate with that?

Deprecated code

There is some deprecated code that's suppressed. Needs a look

LDAP

One of the issues I've always been struggling with is the use of in LDAP terms 'Common Names'

Use LDAP to authenticate and authorize a user, but I can't get a common name to use in UI's or data recording.

Shiro wouldn't be able to replace a general user details store, but we should think about making it easier to expose it out of the box (without implementing a custom realm and principal type)

JWT

JWTs only make sense if they are used:
1. stateless, i.e. no session
2. not as a cookie replacement
3. not as a authz replacement (it should most of the times only carry small authc data)

That said, if a user comes with a bearer token, shiro bears two challenges:
1.) The jwt can easily be validated in the realm, just implement doGetAuthenticationInfo and check issuer, date and signature. That's easy.
2.) If you need to extract authz data, well that's a different problem. if you hit that method, you do not have the key in hand - just look at the method signature:
protected AuthorizationInfo doGetAuthorizationInfo(final PrincipalCollection principals)

So you need to store it in a small cache, which does not feel right. Or just look up everything from a 3rd datasource, like your DB. But then, you can just skip this Realm for the Authc part and have a more general authc strategy.

That said, for multiple realms, just imagine this:
1. Authc via JWT
2. Authc via LDAP
3. Authc via static config file

But for all three realms you want to look up your own database for authorization. You need to implement your own delegator. And I think it is not easy to understand this as a shiro newbie.

Cache attributes

Cache issue between authc and authz.

OSGi

OSGi-centric: but how about a restructuring around OSGi services and DS components providing these services?

Issues about ThreadLocal

https://issues.apache.org/jira/projects/SHIRO/issues/SHIRO-799

https://issues.apache.org/jira/projects/SHIRO/issues/SHIRO-763

https://issues.apache.org/jira/projects/SHIRO/issues/SHIRO-796 (move away from ThreadLocals)


JSR-375 Java EE Security API

We could easily implement JSR-375 (the official JavaEE Security API). It is a subset of Shiro's features, but uses Annotations for configuration.

3.x or later (Jakarta)

API & Specification: https://github.com/eclipse-ee4j/security-api

TCK for 2.0.1: https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9/promoted/security-tck-2.0.1-tckinfo.txt


How-to-use article:


  • No labels