What’s the next line in the log after it says there was a
TicketValidationException? It looks like most all cases should throw something
back into the logs which will be diagnostically helpful.
To put that in context, in our environment seeing these occasionally is not
unreasonable — we keep
To be clear in Step 4, are you sure that the user is never redirected to
the external service -- i.e. that when you POST back to /cas/login?...
you're simply being served up the success page (200) and not 302'd to
the vendor and then bounced back again? Based on your history, it seems
most
with it. To
summarize, it seems not to be the SAML process itself, but the VOLUME
of SAML processes in a very short time that seems to cause the issue.
On 12/11/14 9:01 PM, Sean Baker wrote:
Now that's interesting -- is that to say that when you see these
rapidly-generated service tickets
and
the SSO server process locks up, taking the other server with it. To
summarize, it seems not to be the SAML process itself, but the VOLUME
of SAML processes in a very short time that seems to cause the issue.
On 12/11/14 9:01 PM, Sean Baker wrote:
Now that's interesting
for information go pretty much ignored by students
and faculty alike at this time.
Dave
On 12/10/14 8:14 PM, Sean Baker wrote:
Your access logs should show the individual SAMLRequest's generated by
Google; if it's rejecting your assertions in some automated way you
should see a new SAMLRequest each
Your access logs should show the individual SAMLRequest's generated by
Google; if it's rejecting your assertions in some automated way you
should see a new SAMLRequest each time. If it's the same request over
and over, one might infer a more local issue (not definitively mind you;
just much more
Michal,
It sounds like you’re running up against cookie domain issues here. That is,
when you’re logging into an internal service your browser is given a Ticket
Granting Ticket, or TGT (in the form of an HTTP cookie) for login.example.com.
When you sign into an additional internal service,
IMO the risk is that instead of validating the ticket that the user would
actually use the ticket before the intended user could.
The problem with using this argument against allowing non-SSL services, though,
is that if I am an MITM attacker capable of intercepting
that they are in the 'down
state' I can sucessfully authentication/access into a cas-ified apache
instance, but not the service management.
Thanks,
Aaron
On 10/20/2014 12:34 PM, Sean Baker wrote:
Try the below:
https://mail-archives.apache.org/mod_mbox/tomcat-users/201302.mbox/%3c512559f7.4080...@gmail.com%3E
I may be oversimplifying, but what about changing the trustedIssuerDnPattern to
“CN=.*”? It’s formally a regex pattern, so while I’ve never tried a plain
asterisk there, it shouldn’t work.
--
Ne Desit Virtus,
Sean R. Baker
1LT, MS
United States Army
Office #: (301) 319-0712
Email:
Before we spend time reinventing the wheel around here, has anyone out there
integrated CAS with CA’s Service Desk Manager?
Thanks!
--
Ne Desit Virtus,
Sean R. Baker
1LT, MS
United States Army
Office #: (301) 319-0712
Email: sean.ba...@usuhs.edu
--
You are currently subscribed to
We’re also using SPNEGO (Kerberos) to do our single sign-on solution here, and
wanted to jump in to clarify that Kerberos is a protocol and not a type of
server in this context. As such, when using this setup, the AD Domain
Controller speaks Kerberos with the end-user and with the CAS server,
Your browser is remembering which certificate to use, and so long as it
has not been 'locked' (as in the case of a hardware token, lockable
[software] keychain, encrypted key, etc) will continue to simply use it
for as long as the browser as open. Other browsers like Apple's Safari
will even
13 matches
Mail list logo
