On Wed, 06 May 2009 14:08:19 -0400, Eric Pierce wrote
With OpenLdap, you'll need to use the ppolicy overlay
(http://linux.die.net/man/5/slapo-ppolicy) to enforce password policies at the
server level. The purpose of the CAS module wasn't to enforce the policies, I
just wanted to give the user
That got me farther, but new error:
21:46:15,229 ERROR [AbstractKernelController] Error installing to Start:
name=persistence.unit:unitName=#CasPersistence state=Create
java.lang.ClassCastException: org.hibernate.ejb.HibernatePersistence cannot
be cast to
jBoss classloader strategy is very powerful if you understand it... but it can
bite you since it does not necessarily follow the JEE standard.
Instead of deploying your WAR file... try encapsulating the WAR in an EAR
and use a META-INF/jboss-app.xml to enforce isolation. The content would
be
It sounds like the default login-weblow.xml is being used for some reason,
make sure it has the following sections:
action-state id=submit
action bean=authenticationViaFormAction method=submit /
transition on=warn to=warn /
transition on=showExpiredPassView
I'm also facing some logout troubles. All the filters and the listener
are implemented as in the example web application and as described in
this thread. The client app is completely dependent on the credentials
provided by the AssertionThreadLocalFilter , so if the assertion
holder
Hi All,
We are having an issue with a two node cluster CAS 3.2.1 and uPortal 2.6. We
have the two nodes behind a BIGip F5 loadbalacer. When CAS authenticates a
uPortal user, I get the following error (below) from uPortal. We only get the
error when the two nodes are running. If just one node
Dear All,
The problem in the log file was
Caused by: org.jboss.cache.CacheException: Unable to fetch state on startup
For very large TreeCache's the default retrieval time for a cluster node is to small and
needs to be increased so the node can retrieve the current state from the other node
whenever the logout
is fired in CAS, obviously a request is sent to the service, which simply
redirects this request back to CAS. So it looks like it's treating the
logout-command just as a regular request. What could be the reason for this
behaviour?
This could happen if you do not have the
We are having an issue with a two node cluster CAS 3.2.1 and uPortal 2.6. We
have the two nodes behind a BIGip F5 loadbalacer. When CAS authenticates a
uPortal user, I get the following error (below) from uPortal. We only get the
error when the two nodes are running. If just one node is
Hi Everyone,
The next edition of the monthly Jasig Newsletter will be published on
or about Tuesday May 19th, 2009.
If your institution or company has items of interest to the Jasig
community, please submit them via email to newsletter at
jasig dot org by Monday, May 18th, 2009.
Many thanks,
My filter setup looks like this:
!-- FILTERS --
filter
filter-nameCAS Single Sign Out Filter/filter-name
filter-classorg.jasig.cas.client.session.SingleSignOutFilter/
filter-class
/filter
filter
11 matches
Mail list logo