You have to write a class which implements org.apache.shiro.realm.Realm or
extends one of the existing Realms in that package and add it to your Shiro
configuration.
Inside your custom Realm you would have to lookup user credentials stored in
your Weblogic server and create an AuthenticationToken
Years ago plans were announced to add CDI support into Shiro. Now, I wonder
what happened to that plan?
After all, Harald Wellmann generously provided his PAX Shiro implementation
to the community - so what is keeping it from getting integrated?
https://issues.apache.org/jira/browse/SHIRO-337
I believe it to be OK if you include the fix in the 1.4 version even if it
breaks some existing applications. After all, the 1.4 release is a major
upgrade - so changes in behavior are to be expected.
--
Sent from: http://shiro-user.582556.n2.nabble.com/
@Brian: Is this behavior of FirstSuccessfulStrategy by design or is it a bug?
To me it seems wrong that authorization is checked against a realm which was
not authenticated against - after all, that second authentication might
fail, if it were to be tried.
--
Sent from:
You have to implement your own CacheManager and Cache and configure Shiro to
use them. These are my classes for Infinispan; you can use them as examples
for your Redis implementation:
shiro.ini
[main]
...
securityManager.cacheManager = $cacheManagerInfinispan
...
This is what we use in a bean annotated with @Startup @Singleton:
@PostConstruct
public void initializeShiro() {
String iniFile = retrieveFromDatabase(); // real implementation
omitted for clarity
Ini ini = new Ini();
ini.load(iniFile);
String
One other possibility, though far from perfect, is to have
shiroFilter.setFilterChainDefinitionMap(definitionsMap) only accept
LinkedHashMap or TreeMap as parameters instead of accepting just any Map. I
think those are the only Map implementations in standard Java SE which
retain order.
--
View
I believe the only way to achieve the desired behavior is to make 'log spam'
the default behavior and allow us to override it via an option in Shiro's
configuration, instead of hard coding log levels.
Brian Demers wrote
> There have been a couple issues on either side of this.
>
> These
Sorry, I have no idea where the 302 might originate from.
You would use the web form for the web client and BasicAuth for the requests
from the desktop client to the REST services since the desktop client is
probably not designed to handle web pages (string parsing is just sooo
awful). If you
If you cannot log in then something is wrong - did an exception get thrown or
some other hint show up as to what might be the cause?
A failed login attempt should return an HTTP 401 response so as to behave in
a way that most people would expect - but there is no technical reason for
it.
Basic
If you configure the FormAuthenticationFilter to protect every HTTP request
in the [urls] section (/** = authc) then users would not be able to access
your login page without being authenticated. So, in order to let users
access the login page you specify it in the ini file which causes Shiro to
I think I do not understand your questions - if Shiro has been already
initialized on the server for the web application, then, why do it a second
time? What do you mean with 'work with / access the ini file"? What do you
mean by "access the FormAuthenticationFilter"? You do not need to access it,
The Shiro environment is only initialized on the server - *not* on the
clients. The clients need not know Shiro even exists, since they only use
regular HTTP requests with either Basic Authentication (desktop client
[REST]) or Form Authentication (Browser [HTTP session]). The server is
initialized
The subject is a kind of proxy to the underlying SecurityManager meaning some
methods of Subject actually just trigger calls to the SecurityManager which
in turn triggers methods on the configured realms.
You would use subject.isAuthenticated() on the server's HTTP interface to
determine whether
I believe JSPs offer no benefit - they have been replaced by JSF within JEE.
You can use servlets without JSP or JSF, but if you do use JSP or JSF you
will need an application server like Wildfly or Glassfish or have to include
the required components into Tomcat yourselves.
You do not check
All browsers handle sessions for you, so on the web client you need *not*
check sessions but instead just do form authentication:
https://shiro.apache.org/webapp-tutorial.html#step3 (you need not use a JSP
page, any POST operation that results in the same HTTP request will work)
And then the
Welcome Andreas, glad to have you on board!
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/New-Committer-Andreas-Kohn-tp7581150p7581154.html
Sent from the Shiro User mailing list archive at Nabble.com.
I love Shiro.
That being said I believe it is ill suited to situations like the one you
describe. We sell a ECM / DMS product where customers may store millions of
documents. If we were to store every document's permissions with the user or
role that would not only mean millions of permissions
I do not see any RolePermissionResolver attached to your activeDirectoryRealm
which would look something like this:
rolePermissionResolver =
de.scsynergy.elementary.qi.shiro.ActiveDirectoryRolePermissionResolver
activeDirectoryRealm.rolePermissionResolver = $rolePermissionResolver
In order for
The following screenshot shows what Firefox logs when doing Basic
Authentication with Shiro and I am convinced Chrome does not / should not
filter out any related packages. Digest Authentication and Basic
Authentication work almost identically so if Chrome does not log that 401
HTTP response, then
Sounds like a great idea. And while I am pretty sure you are planning to
implement this and only forgot to mention it, I think we would need '$role'
in addition to '$user'.
Concerning 'and Integer getClearanceLevel()' I would suggest a slightly more
versatile approach where getClearanceLevel()
That exception occurs when your Shiro environment has not been initialized
correctly.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/How-To-Extend-BasicHttpAuthenticationFilter-and-configured-it-in-spring-based-application-tp7581092p7581094.html
Sent from the Shiro
Cool, that certainly is good news.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/ANNOUNCE-Community-Update-Working-on-1-3-Release-Dedicated-Shiro-Staff-tp7581077p7581079.html
Sent from the Shiro User mailing list archive at Nabble.com.
I suspect the problem arises from Shiro interpreting the '#' sign as the
start of a comment, so you might want to try and escape it '\#'. Or maybe
you can use some other character instead of the # sign in your URLs?
--
View this message in context:
The URI you are calling seems weird as it is missing the context root a.k.a.
the name of the application. I would have expected to see something like
http://localhost:8080/MyApplicaion/callback.
Apart from that Shiro filters are subclasses of
If you want to use Shiro on the frontend, too, and have backend and frontend
share their authentication state, then you would need to use ehcache and
either terracotta or hazelcast on both machines to synchronize Shiro
sessions between frontend and backend servers.
--
View this message in
Your frontend server only serves up the html, css and javascript page, right?
Then you can either code your html / javascript to authenticate to your
backend and store the Shiro session cookie with the client's web browser or
have your frontend serve as a proxy for authentication by passing
If applications reside on different cluster nodes, then yes, you will need
either terracotta or hazelcast.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Questions-about-poor-mans-SSO-tp7581009p7581017.html
Sent from the Shiro User mailing list archive at Nabble.com.
Are we talking web applications here or not? Because, if we are talking about
web applications hosted on an application server, then you can have the
application server supply the required class 'com.john.appone.Person'
instead of packaging it along with the application. This way any web
Since you have no web.xml in a cxf project you need a class which extends
EnvironmentLoaderListener to initialize Shiro. Here is our class that we use
- I omitted everything not related to Shiro from this posting (we use
https://ops4j1.jira.com/wiki/display/PAXSHIRO/OPS4J+Pax+Shiro for CDI
I am not sure whether this information will help you, but here is some code
we use to initialize Shiro programmatically from an entry in MongoDB (we use
https://ops4j1.jira.com/wiki/display/PAXSHIRO/OPS4J+Pax+Shiro for CDI
integration). Notice how we add the realm 'CamelRealm.CAMELREALM (=
This post here was a great starting point to get SSO working across multiple
war files. I did have to adjust some things because I use WildFly instead
of Glassfish application server:
I noticed some bugs in 9.0.2 which are not present in 9.0.1 - maybe the
errors are related to the specific WildFly version?
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Help-401-Unauthorized-but-using-full-access-in-ini-file-tp7580896p7580900.html
Sent from the Shiro
Concerning the session, maybe this line of code will help you which we use to
reconstruct a subject from its session id (this is needed because we use
multiple Apache Camel contexts):
Subject subject = new
Subject.Builder().sessionId(shiroSessionId).buildSubject();
where shiroSessionId has
No, this will not work since roles and permissions from the ini file are only
applied if authentication is done via ini file, too.
Aside from that, ini file authentication and authorization are not meant to
be used for production uses but for quick and dirty development. In a
production
You could have a look at:
https://ops4j1.jira.com/wiki/display/PAXSHIRO/JSF+Support
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Shiro-web-in-JSF-Page-not-working-tp7580779p7580847.html
Sent from the Shiro User mailing list archive at Nabble.com.
What do you plan to use as a backend for authentication and authorization -
be it with Shiro or without? I am asking this because if you have your user
and role information stored in some data store (database, ldap ...) anyhow
then all you need to do is keep track of who is currently logged in in
This happens whenever code is executed for which Shiro has not been
initialized properly beforehand.
We had some issues with Primefaces Push (atmosphere), too, so we simply
wrote our own websocket code for push functionality. Research on the
internet brings up statements, that Shiro would break
Here is what our login methods look like (MongoDB realm):
public void login() {
try {
AuthenticationToken at = (new UsernamePasswordToken(username,
password, false));
subject.login(at);
You have to write your own realm:
public class MongoRealm extends AuthorizingRealm implements Serializable {
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
pc) {
// retrieve user's roles and permissions from database, then
Of course we all know how to implement AuthorizingRealm; this whole forum is
full of examples on how to do it. Two examples I found in under 15 seconds:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-MongoDB-Realm-td7579029.html
http://shiro-user.582556.n2.nabble.com/Example-Shiro-Active-Directory-Realm-with-role-gt-permission-mapping-td7579030.html
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/LDAP-for-authentication-only-and-query-authorization-information-by-JDBC-tp7580797p7580798.html
I do not know whether anyone would consider it best practice, but we keep
Shiro subjects separate from any additional information. Instead we have a
CDI bean which is initialized on login using the subject principal's name -
which to this end obviously has to be unique - and then look that user up
I use EhCache for this. Here is where I got my information from:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-SSO-for-multiple-WAR-files-with-EhCache-on-Glassfish-td7579037.html
--
View this message in context:
1. Your realm reads its users, roles and permissions from some backend system
(e. g. database). So user A would have a role R which has the VIEW
permission. Now, all you need do is change the permission of role R from
VIEW to READ and WRITE inside the database. This change will only take
effect
I think you would need to do programmatic login so that you can catch the
individual exceptions that may be thrown.
public void login() {
try {
AuthenticationToken at = (new UsernamePasswordToken(username,
password, false));
subject.login(at);
} catch
"I can get the list of groups(roles) for the user and could use that to
populate the GroupPermission object, but there's no access info in LDAP for
the user so I don't know where/how to insert the access that a user needs to
complete this task."
You might be able to use a RolePermissionResolver
Here is an example for a MongoDB realm:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-MongoDB-Realm-td7579029.html
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/How-implement-a-Realm-in-Shiro-tp7580692p7580698.html
Sent from the Shiro User mailing list archive
[main]
// is there a line missing which would look something like 'shiro =
org.apache.shiro.web.filter.authc.PassThruAuthenticationFilter' ?
shiro.loginUrl = /login.jsp // this line tells Shiro what to do when an
unauthenticated user tries to acces a secured page: redirect the user to
/login.jsp
You can verify whether a user / role has access to the record by including
these lines at the very beginning of the method which retrieves it from your
database:
Set permissions = new HashSet<>();
permissions.add(new WildcardPermission("record:read:user"));
permissions.add(new
As far as I know Shiro uses the crypto libraries included in the JDK and just
exposes them in a more user friendly way.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Strange-Sha256Hash-implementation-tp7580691p7580700.html
Sent from the Shiro User mailing list archive
authc.successUrl means after the authc filter has successfully validated the
user redirect her to /home.jsp
/login.jsp = anon means do not apply any filter to /login.jsp, not even
authc, which means authc is never called and therefore never notices a
successful login attempt and therefore does not
Yes - concerning the servlet
Yes - concerning question 1.
Yes - concerning question 2.
No, instead you should use authc.loginUrl = /login.xhtml which tells Shiro
to exempt '/login.xhtml' from permission checks.
--
View this message in context:
FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
throws an UnkownSessionException because subject.logout() has already
invalidated the Shiro session SSOcookie. The ExternalContext does not have
access to the JSESSIONID session.
--
View this message in context:
We found a solution to our problem:
We implemented an HttpSessionListener whose sessionCreated(HttpSessionEvent
se) method fires when the JSESSIONID session is created and we additionally
call subject.getSession() to retrieve the Shiro session 'SSOcookie'. Then we
save both to an
Update
It seems as though the problem arises from using
org.apache.shiro.web.session.mgt.DefaultWebSessionManager
in combination with
cookie = org.apache.shiro.web.servlet.SimpleCookie
cookie.name = SSOcookie
The result is 2 different sessions with 2 different session cookies and 2
redundant
I have the problem that session scoped beans are not destroyed before the
session times out (30 minutes).
Therefore I have two questions regarding the following logout procedure:
1. Is this the right way to use shiro logout (see logout() below)
2. What would be the proper way to destroy
If with 'LDAP' you mean 'Active Directory', then this thread might help:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-Active-Directory-Realm-with-role-gt-permission-mapping-td7579030.html
--
View this message in context:
Just on a side-note,
/users/** = authcBasic
leaves your user-password as plain-text and therefor totally vulnerable to
eavesdropping.
In production environments I suggest you change that line to
/users/** = ssl[insert your port number here], authcBasic
for instance my server
/users/** =
I do not know whether my way of doing things is better but I will describe it
anyway:
I wrote Facade / DAO methods whose invocations are restricted to certain
Permissions; in your case that would look something like:
// method invocation is restricted to the any:view Permission which I
presume
Your webapps are not sharing their sessions with each other. You can use
EhCache to do that like it is described here:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-SSO-for-multiple-WAR-files-with-EhCache-on-Glassfish-td7579037.html
One important thing to keep in mind is to place some of
I doubt this is the problem, but will ask nevertheless: Maybe character
encoding is configured differently on both platforms UTF8 versus
ISO-something? The entered credentials would not match the database's on
occasion in this case.
--
View this message in context:
Shiro starts to shine when the features you need are not provided by the
other authentication and authorization frameworks, e. g. NoSQL support or
your users and roles are in different relational databases or one
authentication framework to serve web and non-web applications
simultaneously. These
I use Shiro with JEE7 on Wildfly in combination with
https://github.com/ops4j/org.ops4j.pax.shiro and still have not found any
security framework that is as lightweight, flexible and easy to use as
Shiro. But I sure hope that CDI will be officially supported by Shiro in
version 2.
--
View this
The only thing that I noticed is that you login via the security manager
this.securityManager.login(this.subject, token);
whereas I login via the subject
subject.login(new UsernamePasswordToken(username, password, isRemembered));
I do not know whether both ways produce the same results.
On a
In this example the author loads roles and their corresponding permissions
from MongoDB inside his custom made Shiro realm:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-MongoDB-Realm-td7579029.html
Basically any Realm that extends AuthorizingRealm
Regarding your second question this might help:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-Active-Directory-Realm-with-role-gt-permission-mapping-td7579030.html
--
View this message in context:
Hi,
I have been trying to secure my SOAP webservices with Apache Shiro but I am
stuck: I managed to either restrict everything or nothing, but what I want
is to have everything secured except for access to the wsdl which should be
open to unrestricted access.
/SoapService?wsdl should be open to
Correct me if I am wrong, but Apache Shiro does *not* secure your web
application against XSS. Instead Apache Shiro itself is invulnerable to XSS
- meaning e. g. Javascript attacks targeting Shiro will not succeed.
--
View this message in context:
In order to grant a permission to a role, you need a method. This method in
turn may only be executed by roles with a certain permission.
public void grant(Role role, Permission permission) {
org.apache.shiro.subject.Subject subject =
SecurityUtils.getSubject();
if
1. I suppose you are coding a project which does not have a web.xml and are
wondering how to initialize Shiro. I have not done this myself without
web.xml but assume you must subclass
org.apache.shiro.web.env.EnvironmentLoaderListener and attach the annotation
@WebListener to this subclass to have
This example is for active directory which is an ldap server at its core,
maybe it can get you started:
http://shiro-user.582556.n2.nabble.com/Example-Shiro-Active-Directory-Realm-with-role-gt-permission-mapping-td7579030.html
--
View this message in context:
72 matches
Mail list logo
