[
https://issues.apache.org/jira/browse/SHIRO-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061782#comment-13061782
]
Elhanan Maayan commented on SHIRO-311:
--------------------------------------
i'm attempting to support a use where a use where authentication was allready
done internaly.
it started with learning how to use SSO with spnego as i investigated how to
use JGSS api's to authenticate myself against active directory, with the idea
of using the ticket recived, as the token for shiro.
after learning about the usage i discovered it wasn't really needed as SSO was
being done at servlet filter level, so trying to use the api's would also be
redundant and in-efficient (as authentication for each user would be done twice)
but still, it's a common use case and shiro should be able to support this more
native way then letting users override realms and create no-op tokens by
themselves.
in my opinion the optimal solution for would extend it's existing servlet
filter (or create a new one) to do the this functionally as this
http://spnego.sourceforge.net
although this does not over the desktop area. to my understanding nor is java
http://stackoverflow.com/questions/545667/how-to-use-windows-login-for-single-sign-on-and-for-active-directory-entries-for
in a more generic way, you could develop something like an SSORealm, and
provide a default implementation using spnego and let users override id in
special cases (jcifcs etc..)
> allow the use of shiro as Autorization only framework
> -----------------------------------------------------
>
> Key: SHIRO-311
> URL: https://issues.apache.org/jira/browse/SHIRO-311
> Project: Shiro
> Issue Type: New Feature
> Components: Authentication (log-in), Authorization (access control)
> , Configuration, Integration: JEE
> Affects Versions: 1.1.0
> Environment: java 6 , active directory
> Reporter: Elhanan Maayan
>
> currently shiro uses login as the only entry point to the application which
> uses authentication and authorization procedures, defined in the chosen
> subclasses realm.
> however in many organization's intranet , a domain authentication is already
> employed making the authentication process in shiro redundant.
> in order to keep consistency with the framework, a new type of Token should
> be created called AuthenticatedToken. the difference is shiro would be able
> to create such a token in it's filter by inspecting getRemoteUer of the HTTP
> request, which according to the spec is !=null only when the user is
> authenticated.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
