Skip to content
This repository was archived by the owner on Dec 12, 2018. It is now read-only.

Updating Readme #23

Open
brentstormpath wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

Updating Readme #23

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7577c4c
Update README.md
brentstormpath Jan 22, 2015
19d1c6b
Update README.md
brentstormpath Jan 22, 2015
7518993
Updating Readme and adding separate changelog file.
brentstormpath Jan 22, 2015
ba09c9c
Update README.md
brentstormpath Jan 22, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
114 changes: 25 additions & 89 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,116 +2,52 @@

# Apache Shiro plugin for Stormpath #

Copyright © 2013-2014 Stormpath, Inc. and contributors. This project is open-source via the [Apache 2.0 License](http://www.apache.org/licenses/LICENSE-2.0).
The `stormpath-shiro` plugin allows an [Apache Shiro](http://shiro.apache.org)-enabled application to
use the [Stormpath](http://www.stormpath.com) User Management & Authentication API for all authentication and access control needs.

The `stormpath-shiro` plugin allows an [Apache Shiro](http://shiro.apache.org)-enabled application
use the [Stormpath](http://www.stormpath.com) User Management & Authentication service for all authentication and access control needs.
Stormpath is a User Management API that reduces development time with instant-on, scalable user infrastructure. Stormpath's intuitive API and expert support make it easy for developers to authenticate, manage, and secure users and roles in any application.

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](https://github.com/stormpath/stormpath-shiro/wiki).
## Documentation

### Build Instructions ###
Stormpath offers usage documentation and support for the Apache Shiro Plugin for Stormpath [in the wiki](https://github.com/stormpath/stormpath-shiro/wiki). Please email support@stormpath.com with any errors or issues with the documentation.

This project requires Maven 3 to build. Run the following from a command prompt:

`mvn install`

## Change Log

### 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](https://github.com/stormpath/stormpath-shiro/issues/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](http://docs.stormpath.com/rest/product-guide/#custom-data) feature. You can add and remove permission to an Account or Group by modifying that account or group's CustomData resource. For example:

```java
Account account = getAccount(); //lookup account
## Links

//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();
```
Below are some resources you might find useful!
- [Apache Shiro Webapp Tutorial](http://shiro.apache.org/webapp-tutorial.html)
- [Stormpath-Shiro Sample Webapp](https://github.com/stormpath/stormpath-shiro-web-sample)

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.
**Stormpath Java Support**
- [Stormpath API Docs for Java](https://docs.stormpath.com/java/apidocs/)
- [Stormpath Java Product Guide](https://docs.stormpath.com/java/product-guide/)
- [Stormpath Java SDK](https://github.com/stormpath/stormpath-sdk-java)
- [Stormpath Servlet Plugin for Java Webapps](https://docs.stormpath.com/java/servlet-plugin/)

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.
## Contributing

The `CustomDataPermissionsEditor` will save the permissions as a JSON list in the CustomData resource, under the default `apacheShiroPermissions` field name, for example:
Contributions, bug reports and issues are very welcome. Stormpath regularly maintains this repository, and are quick to review pull requests and accept changes!

```json
{
... any other of your own custom data properties ...,
You can make your own contributions by forking the develop branch of this
repository, making your changes, and issuing pull request on the develop branch.

"apacheShiroPermissions": [
"perm1",
"perm2",
...,
"permN"
]
}
```
If you would like to change the default field name, you can call the `setFieldName` method:
## Build Instructions ##

```java
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:

```ini
[main]

cacheManager = my.shiro.CacheManagerImplementation
securityManager.cacheManager = $cacheManager
This project requires Maven 3 to build. Run the following from a command prompt:

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

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:
Release changes are viewable in the [change log](changelog.md)

```ini
# ...
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.
## Copyright ##

See ClientFactory `setCacheManager` and `setStormpathCacheManager` JavaDoc for more.
Copyright © 2013-2015 Stormpath, Inc. and contributors.

### 0.3.1
This project is open-source via the [Apache 2.0 License](http://www.apache.org/licenses/LICENSE-2.0).

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.



Expand Down
93 changes: 93 additions & 0 deletions changelog.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
## Change Log ##

### 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](https://github.com/stormpath/stormpath-shiro/issues/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](http://docs.stormpath.com/rest/product-guide/#custom-data) feature. You can add and remove permission to an Account or Group by modifying that account or group's CustomData resource. For example:

```java
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:

```json
{
... 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:

```java
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:

```ini
[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:

```ini
# ...
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.