You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Cservenak, Tamas (JIRA)" <ji...@apache.org> on 2012/05/22 17:34:40 UTC

[jira] [Created] (SHIRO-366) Make possible to dynamically select the Realm that participates in authc/authz

Cservenak, Tamas created SHIRO-366:
--------------------------------------

             Summary: Make possible to dynamically select the Realm that participates in authc/authz
                 Key: SHIRO-366
                 URL: https://issues.apache.org/jira/browse/SHIRO-366
             Project: Shiro
          Issue Type: Improvement
            Reporter: Cservenak, Tamas


Right now, Shiro will always use all the configured Realms (one or more) to perform authc/authz actions.

But, there might be situations where a "targeted" approach would be needed.

One simple (but breaking) change would be to extend AuthenticationStrategy iface, to somehow make it able to tell "skip this realm" to ModularRealmAuthenticator (as beforeAttempt and afterAttempt already exists)?

===

A use case would be to make Shiro able to authc/authz targeting different realms using same "mech" (like HTTP Basic for example) against different sources, unlike today, where _all_ realms will be always used.

For example, a single App could have:
* Realm A using LDAP A
* Realm B using LDAP B
* Realm C ...

(LDAP A and LDAP B might even have overlapping usernames but those usernames are not _same_ users, they have different perms etc)

Today, Shiro will _always_ consult Realms A, B, C (one can affect the "strategy" only).

But, based on some conditions (IP of incoming HTTP request? User Agent? Path? etc), I'd like to be able to do:
* use A realm only
* use A and C realm only
* use B only
etc.

But the point is, that _client should be unaware_ of this (so, it would not need to pass in some HTTP Header saying "I need realm B" etc). It should simply stick with plain HTTP Basic for example.

Other ideas welcome, if I missed something in Shiro already making this possible!


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira