stormpath / stormpath-shiro

Apache Shiro plugin for Stormpath

#Stormpath is Joining Okta We are incredibly excited to announce that Stormpath is joining forces with Okta. Please visit the Migration FAQs for a detailed look at what this means for Stormpath users.

We're available to answer all questions at [email protected].

Apache Shiro plugin for Stormpath

Copyright © 2013-2016 Stormpath, Inc. and contributors. This project is open-source via the Apache 2.0 License.

The stormpath-shiro plugin allows an Apache Shiro-enabled application use the Stormpath User Management & Authentication service for all authentication and access control needs.

Pairing Shiro with Stormpath gives you a full application security system complete with immediate user account support, authentication, account registration and password reset workflows, password security and more - with little to no coding on your part.

Usage documentation is in the wiki.

Build Instructions

This project requires Maven 3 to build.

Basic Build

Run the following from a command prompt:

mvn install

Build with Docs

Install sphinx: pip install sphinx or using virtualenv:

pushd extensions/servlet/docs
virtualenv docs
source docs/bin/activate
pip install -r requirements.txt
popd

Then run: mvn install -Pdocs -Psphinx-docs

Run the TCK

Clone the https://github.com/stormpath/stormpath-framework-tck project and run mvn clean install -P\!run-ITs Then run mvn install -Prun-TCK

Change Log

0.8.0 RC1

• Upgraded Shiro dependency to latest release candidate: 1.4.0-RC2
• Upgraded Stormpath SDK dependency to latest released version: 1.1.4
• Moved Shiro specific code to the Apache Shiro Repository
• Moved default configuration to stormpath-shiro.ini
• Default configuration now disables Shiro's session tracking (using stateless JWTs in place)
• Added JAX-RS example
• Added Dropwizard + AngularJS example

0.7.2

• Fixed validation problem in web-fragment.xml
• Upgraded Stormpath SDK dependency to latest released version: 1.1.1

0.7.1

• Corrected Spring test dependencies scope
• Spring modules now correctly set the EventBus instance on the SecurityManager

0.7.0

• Upgraded Shiro dependency to latest stable release of 1.3.2
• Upgraded Stormpath SDK dependency to latest released version: 1.0.4
• Added stormpath-shiro-servlet-plugin to automatically configure Shiro to use a Stormpath realm and use Stormpath login UI out of the box
• Added spring-boot starters for both web and non-web applications, see stormpath-shiro-spring-boot-starter and stormpath-shiro-spring-boot-web-starter
• Added examples for core, servlet, spring-boot, and spring-boot-web extensions.

0.6.0

• Upgraded Shiro dependency to latest stable release of 1.2.3
• Upgraded Stormpath SDK dependency to latest released version: 1.0.RC2
• Issue 6: Fixed bug that prevented Authentication data to be removed from cache after a successful logout.

0.5.0

• Upgraded Stormpath SDK dependency to latest stable release of 0.9.1
• Added Permission support! It is now possible to assign Shiro permissions to Stormpath Accounts or Groups by leveraging Stormpath's newly released CustomData feature. You can add and remove permission to an Account or Group by modifying that account or group's CustomData resource. For example:

Account account = getAccount(); //lookup account

//edit the permisssions assigned to the Account:
new CustomDataPermissionsEditor(account.getCustomData())
    .append("user:1234:edit")
    .append("document:*")
    .remove("printer:*:print");
    
//persist the account's permission changes:
account.save();

The same CustomDataPermissionsEditor can be used to assign permissions to Groups as well, and assumes 'transitive association': any permissions assigned to a Group are also 'inherited' to the Accounts in the Group.

In other words, an account's total assigned permissions are any permissions assigned directly to the account, plus, all of the permissions assigned to any Group that contains the account.

The CustomDataPermissionsEditor will save the permissions as a JSON list in the CustomData resource, under the default apacheShiroPermissions field name, for example:

{
    ... any other of your own custom data properties ...,

    "apacheShiroPermissions": [
        "perm1",
        "perm2",
        ...,
        "permN"
    ]
}

If you would like to change the default field name, you can call the setFieldName method:

new CustomDataPermissionsEditor(account.getCustomData())
    .setFieldName("whateverYouWantHere")
    .append("user:1234:edit")
    .append("document:*")
    .remove("printer:*:print");

But you'll also need to update your ApplicationRealm's configuration to reflect the new name so it can function - the realm reads the same CustomData field, so they must be identical to ensure both read and write scenarios access the same field. For example, if using shiro.ini:

stormpathRealm.groupPermissionResolver.customDataFieldName = whateverYouWantHere
stormpathRealm.accountPermissionResolver.customDataFieldName = whateverYouWantHere

• The ApplicationRealm implementation now has a default groupPermissionResolver and accountPermissionResolver properties that leverage respective group or account CustomData to support permissions as described above. Prior to this 0.5.0 release, there were no default implementations of these properties - you had to implement the interfaces yourself to support permissions. Now Permissions are built in by default (although you could still provide your own custom implementations if you have custom needs of course).

0.4.0

• Upgraded Stormpath SDK dependency to latest stable release of 0.8.1
• Added CacheManager/Cache bridging support. This allows the Stormpath SDK to use the same caching mechanism that you're already using for Shiro, simplifying cache configuration/setup. For example:

[main]

cacheManager = my.shiro.CacheManagerImplementation
securityManager.cacheManager = $cacheManager

# Stormpath integration:
stormpathClient = com.stormpath.shiro.client.ClientFactory
# etc...
stormpathClient.cacheManager = $cacheManager

If for some reason you don't want the Stormpath SDK to use Shiro's caching mechanism, you can configure the stormpathCacheManager property (instead of the expected Shiro-specific cacheManager property), which accepts a com.stormpath.sdk.cache.CacheManager instance instead:

# ...
stormpathCacheManager = my.com.stormpath.sdk.cache.CacheManagerImplementation
# etc...
stormpathClient.stormpathCacheManager = $stormpathCacheManager

But note this approach requires you to set-up/configure two separate caching mechanisms.

See ClientFactory setCacheManager and setStormpathCacheManager JavaDoc for more.

0.3.1

0.3.1 is a minor dependency fix: the Stormpath Java SDK dependency has been upgraded to reflect its latest 0.8.0 release. This is the only change - no additional features/changes have been made otherwise.

stormpath-shiro's Issues

Login requires at least one HTTP call to the Stormpath API

Hi,

I tried to use the Cache to prevent repeating requests. However, in my implementation on each login attempt there is one request to the server. After reading the code, I recognized that collections requested are not cached:
https://github.com/stormpath/stormpath-sdk-java/blob/stormpath-sdk-root-1.0.RC/impl/src/main/java/com/stormpath/sdk/impl/ds/DefaultDataStore.java#L587

I currently use HTTP Basic Auth for an REST-API. If I send lots of request to my REST-API the responses will be very slow. Here is what is happening:

1. User sends REST-API request with HTTP Basic Auth
2. Start login process
3. Credentials are ok
4. Check for groups: https://github.com/stormpath/stormpath-shiro/blob/stormpath-shiro-root-0.5.0/core/src/main/java/com/stormpath/shiro/realm/ApplicationRealm.java#L430
5. Groups are not cached. Send "slow" HTTP request to Stormpath server.

Is there anything I can do, to cache the group request?

Cheers,
Jens

Upgrade Jackson dependency to version 2

Jackson 1.x is very old and obsolete.
Stormpath APIs should not use it but use 2.x version
Especially since Stormpath Java SDK is using Jackson 2.x

Thank you

Upgrade Stormpath Java SDK to version 1.0.RC

Stormpath customData access

I have looked all over the place but can't seem to find how to access the customData for a logged in user. The stormpath-shiro plugin is setup and working. I can login as a user and the permissions are correct as well. I just need to be able to access the customData provided by stormpath.

Here is my code (jRuby on Rails):

    token = UsernamePasswordToken.new(username, password)
    token.setRememberMe(false)
    begin
        current_user.login(token)
        puts current_user.getPrincipals() # Doesn't contain the custom data.
        ...
        # Not sure how to access the customData for the logged in user.
        # Any help would be greatly appreciated.

Login for already logged-in user succeeds despite wrong credentials

The current implementation of the plugin allows the following:

1. Login with valid credentials (username, valid-password) succeeds. If caching is enabled, the username is used as the key for caching.
2. If you login again (without logging out in between), this time with credentials (username, invalid-password) the login succeeds again. This is because a cache entry exists for the username and the cached AuthenticationInfo is compared to what is provided using a AllowAllCredentialsMatcher instance.

A simple resolution would be (although I did not tested it):

1. In com.stormpath.shiro.realm.ApplicationRealm#doGetAuthenticationInfo include the password in the returned AuthenticationInfo instance.
2. Use a SimpleCredentialsMatcher instead of the AllowAllCredentialsMatcher (that is used in AuthenticationRealm#assertCredentialsMatch to verify that the cached credentials actually match).

This way the wrong credentials given for the second login attempt will be rejected and the attempt will fail (as intended).

Authentication failure

Java::OrgApacheShiroAuthc::AuthenticationException (Authentication failed for token submission [org.apache.shiro.authc.UsernamePasswordToken - chason.choate, rememberMe=false].  Possible unexpected error? (Typical or expected login exceptions should extend from AuthenticationException).):
  org.apache.shiro.authc.AbstractAuthenticator.authenticate(org/apache/shiro/authc/AbstractAuthenticator.java:214)
  org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(org/apache/shiro/mgt/AuthenticatingSecurityManager.java:106)
  org.apache.shiro.mgt.DefaultSecurityManager.login(org/apache/shiro/mgt/DefaultSecurityManager.java:270)
  org.apache.shiro.subject.support.DelegatingSubject.login(org/apache/shiro/subject/support/DelegatingSubject.java:256)

Any reason why I would be getting this error now? Our app has been working and for some reason this just started today.

Replace JSP with Velocity

ID Site support for Shiro

WebListener must implement at least one listener interface

Hi,
I tried to set up a demo using the id_site feature and stumbled upon the fact the the IdSiteServlet is annotated with @weblistener, without implementing one of the necessary interfaces. While jetty doesn't care, jboss/wildfly fails to deploy the context because of that. Simply removing the annotation resolves this issue.

Cheers,
Thorsten

(Although this does not belong here, and please point me to the right place if there is one: Can you tell me something about the state of the id_site feature? Will this be released soon? Except for some minor issues, it seems to work fine.)

Add Social Login for Google and Facebook

Deprecated use of ApiKeys

In com.stormpath.shiro.client.ClientFactory the following import

import com.stormpath.sdk.client.ApiKeys;

should be replaced with

import com.stormpath.sdk.api.ApiKeys;

The first one is deprecated

Runtime problem occurs when using latest version of stormpath-sdk (1.0.alpha)

A runtime problem occurs when using the latest version of the stormpath-shiro plugin and the latest version of the Java stormpath-sdk.

NoSuchElementException when reading principals where multiple Realms in use

I have an application that uses multiple Realms (in this particular case an IniRealm and the ApplicationRealm). ApplicationRealm.getAccountHref() assumes that the subject was authenticated against the ApplicationRealm

protected String getAccountHref(PrincipalCollection principals) {
    Collection c = principals.fromRealm(getName());
    //Based on the createPrincipals implementation above, the first one is the Account href:
    return (String) c.iterator().next();
}

When a PrincipalCollection is passed to doGetAuthorizationInfo, the c.size() == 0 so there is no next().

java.util.NoSuchElementException
at java.util.Collections$EmptyIterator.next(Collections.java:3006)

Trapping an empty collection and returning a default/empty SimpleAuthorizationInfo seems the most appropriate solution but that's just a guess.

Stormpath.* properties should take precedence over config in shiro.ini

This is tricky due to how Shiro loads an object graph from the shiro.ini, but from a user perspective, the current behavior is less obvious.

Currently if a user has a shiro.ini that looks like:

[main]
...
stormpathRealm.applicationHref = http://etc..

Then there is NO way of overriding this via the command line using an environment variable of STORMPATH_APPLICATION_HREF or -Dstormpath.application.href=...

This is slightly related to SHIRO-501 (using system properties in the shiro.ini, but not exactly the same.

Add permission editing support using Custom Data

The Stormpath Java SDK 0.9 supports Custom Data. This can be leveraged as a storage/retrieval mechanism for assigning permissions directly to accounts and groups. Add this capability so that Shiro-enabled applications can fully leverage permissions while using Stormpath.

At logout time, Shiro and the new Stormpath Servlet should be logged out

The logout event needs to cause both the Stormpath Servlet and Shiro to be logged out.

Vulnerability when caching is enabled

I use the Stormpath Shiro plugin to implement authentication / authorization in a REST API implementation with HTTP Basic Auth. When I disable caching everything works fine. However, when it is enabled a login attempt with a wrong password succeeds when it is preceded by a successful login attempt.

Looking at the Shiro / Plugin code I think that the problem is that the principal (username) is used as the cache key (which translates into the valid AuthenticationInfo object from the last successful login). However, as a AllowAllCredentialMatcher is used by default, the authentication attempt succeeds even though the password is wrong. Configuring the system to use a SimpleCredentialMatcher does not work either, as the credentials are not stored in the AuthenticationInfo object. As a consequence every login attempt, even those with correct credentials, fails. Hopefully, I'm doing something terribly wrong. My configuration is as follows:

[main]
# Configure the cache manager used to cache authentication results
cacheManager = org.apache.shiro.cache.MemoryConstrainedCacheManager
securityManager.cacheManager = $cacheManager

# Configure the Stormpath client used to access the Stormpath Cloud service.
# Set a Client factory, that configures a proxy and sets the path to the API key
stormpathClient = package.StormpathClientFactory
stormpathClient.cacheManager = $cacheManager

# Configure and set the Stormpath realm
stormpathRealm = com.stormpath.shiro.realm.ApplicationRealm
stormpathRealm.client = $stormpathClient

stormpathRealm.applicationRestUrl = my-url
stormpathRealm.authenticationCachingEnabled = true

securityManager.realm = $stormpathRealm

Coming from a support question: It would be nice to provide OS-independent ApiKey File Reader

One user had the problem that the shiro.ini in Windows was:

stormpathClient.apiKeyFileLocation = C:/stormpathApiKey.properties 

while in Linux:

stormpathClient.apiKeyFileLocation = /home/user/stormpathApiKey.properties 

We might want to provide a way to read properties in an OS-independent way.

BTW, I suggested to user to do:

public class ApiKeyReader extends Reader {
    private static Logger logger = LoggerFactory.getLogger(ApiKeyReader.class);

    private FileReader reader;

    public ApiKeyReader() {
        try {
            String osName = System.getProperty("os.name");
            if(osName.contains("Mac OS") || osName.contains("linux")) {
                reader = new FileReader("/Users/mario/.stormpath/api1Key.properties");
            } else if(osName.contains("windows")) {
                reader = new FileReader("c:/apiKey.properties");
            } else {
                throw new RuntimeException("Unrecognized OS: " + osName);
            }
        } catch (FileNotFoundException e) {
            logger.error(e.getMessage());
        }

    }

    @Override
    public int read(char[] chars, int i, int i2) throws IOException {
        return reader.read(chars, i, i2);
    }

    @Override
    public void close() throws IOException {
        reader.close();
    }
}

Then, in shiro.ini change this:

stormpathClient.apiKeyFileLocation = C:/stormpathApiKey.properties

to

apikeyReader = com.stormpath.test.ApiKeyReader 
stormpathClient.apiKeyReader = $apikeyReader

Authentication Info to stay in cache after logout

@strieflin requested this feature (see #6)

Regarding cached Authentication: What I want to have is that I don't have to hit the Stormpath servers for every request against my REST API. Hence, I don't want to have the cache evicted, since that would make a round trip to the Stormpath servers necessary again. My current strategy is simply not to perform a logout after processing the request.

web-fragment.xml does not validate

The name field contains a - which is invalid for this field.

This does NOT cause a problem with Tomcat or Jetty, but DOES cause issues with Glassfish (and likely others)