>From your logs it looks like egroupware thinks each request is a new
session, and so is authenticating to CAS every time. Most apps set
session Ids with a cookie, so you might want to look at what's happening
on the browser side with Fiddler or HttpFox and see if you're sending a
session cookie o
Hi,
I think that's probably the easiest/most common solution. You have one
authoritative source for usernames & passwords (LDAP or DB). CAS interfaces
with that to service authentication requests. Your individual web applications
use CAS for authentication.
As far as how you want to do th
Thanks all for the replies. I got the Shib admin to recheck his mod_auth_cas
configuration and sure enough Renew was turned on.
He has since turned it off and now we get the SSO experience.
Thanks again,
Bryan
-Original Message-
From: Marvin Addison [mailto:marvin.addi...@gmail.com]
> So we hoping a login to one of our in house CASified applications would
> result in an SSO experience with the 3rd party application. But this is not
> the case. No matter the order the applications are accessed the user is
> always prompted for credentials.
Wonder if it's a service registry iss
> If I remove the CAS configuartion in web.xml welcome.jsp prints
> "/casapp/do/Welcome" otherwise it prints "/casapp/welcome.jsp".
My hunch is that this is caused by CAS redirects, not
HttpServletRequestWrapperFilter. When you say "remove the CAS
configuration," I assume you mean all of it and
Thanks for the feedback. I agree with you observations on the mod_auth_cas
configuration. I don't maintain our Shib installation but asked the admin if
renew was turned on. He claimed it isn't.
-Bryan
From: epie...@mail.usf.edu [mailto:epie...@mail.usf.edu] On Behalf Of Eric
Pierce
Sent: Wedne
Using CAS as the WebSSO for Shibboleth definitely works - I've used it for
2+ years (with Shib 1.3 and 2.x) and haven't had any problems. It's most
likely a config problem with mod_auth_cas because the CAS ticket validation
happens there. You'll probably want to set 'CASDebug On' to see if that
s
We are in the process of deploying a 3rd party application that authenticates
against our 1.3 Shibboleth IDP. Our Shibboleth IDP uses our CAS server for its
authentication (Tomcat using mod_auth_cas).
So we hoping a login to one of our in house CASified applications would result
in an SSO exper
Hi Pietro,
With the .NET CAS client, anyone who can authenticate against your LDAP passes
the authentication step. User.Identity.Name contains the username that
authenticated against the LDAP server after the redirect to the CAS server. In
academic environments, this potentially includes stud
You can start off with changing layout in the style sheet (cas\css\cas.css) and
renaming labels and other login messages
(cas\WEB-INF\classes\messages_en.properties). I did just that without touching
the view.
Hope it helps,
Kostya
-Original Message-
From: acnu [mailto:a...@hotmail.co
Hello Andrew:
The problem is CAS CustomHttpServletRequestWrapper manipulating request URI.
The following are the details
Here are the main files I am using in my sample casclient application
1. web.xml
2. struts-config.xml
3. CustomRequestProcessor.java
4. WelcomeAction.java
5. welcome.js
On Tue, Jul 5, 2011 at 11:55 PM, Scott Battaglia
wrote:
> I was looking through your tutorial. Any particular reason you did this?
> "in Services Management i.e. /cas/services/manage.html Edit service to
> 'Ignore Attribute Management via this Tool'"
> instead of releasing the attribute to the se
> what's the best practice: have One single user database or LDAP for two WebApp
Yes, you will need a consolidated user store. In fact this is not a best
practice but a requirement. You should also consider merging authorization
data from both apps and delivering the relevant attributes to ea
13 matches
Mail list logo
