> Current endpoints:
> /validate - CAS 1.0 protocol
> /serviceValidate & /proxyValidate - CAS 2.0 protocol
>
> Proposed endpoints:
> /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol?
Another +1 for a version protocol-version name-space. Any of /v3/, /3/,
/CAS3/, /CASv3/, /CAS/3/ would b
Hi all,
I think there is a probleme in the traduction for french locales :
I' obtain this error when i'm logging to the service management (from
french login form) :
ERROR [org.springframework.web.servlet.tags.MessageTag] -
javax.servlet.jsp.JspTagException: No message found under code
'managem
> Current endpoints:
> /validate - CAS 1.0 protocol
> /serviceValidate & /proxyValidate - CAS 2.0 protocol
>
> Proposed endpoints:
> /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol?
+1
With this, we are for sure compatible with current clients.
Best,
Robert
--
You are currently s
> Proposed endpoints:
> /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol?
How about a simple /3/...
:-)
Stefan
--
This e-mail and any attachments may contain confidential, copyright and or
privileged material, and are for the use of the intended addressee only. If you
are not the
> Current endpoints:
> /validate - CAS 1.0 protocol
> /serviceValidate & /proxyValidate - CAS 2.0 protocol
>
> Proposed endpoints:
> /v3/serviceValidate % /v3/proxyValidate - CAS 3.0 protocol?
+1
Arguably a win/win solution. New endpoints offer the opportunity to
provide CAS 3 protocol features
+1 for the idea of validating CAS 3.0 at a different endpoint, but the RESTful
API is already using the /v# URL. How about providing the protocol version as
a parameter: /serviceValidate?protocol=3.0 & /proxyValidate?protocol=3.0
--
Eric Pierce
Identity Management Architect
Information Technolo
> If the user attempting to login doesn't have any of
> the attributes being released to that service, the .NET client seems to be
> throwing out the SAML response and redirects the user back to the CAS
> server. The CAS server issues a new SAML response and sends them back to
> the service where
I did some testing with my account and it definitely seems like a bug in the
SAML ticket validator. If the user attempting to login doesn't have any of the
attributes being released to that service, the .NET client seems to be throwing
out the SAML response and redirects the user back to the CA
Folks,
Here my notes from the 2013-11-06 CAS Release Planning Call.
* CAS4 RC2 is essentially feature complete. Deployers are encouraged
to test this release with local overlays and report back any findings.
The one outstanding potentially feature related issue is multi-valued
attributes.
* Mu
I share Adam's perspective here. The big sticking point had been
backward compatibility with current CAS clients. Initially the
thought was to simply add attributes to the current validation
end-point as so many deployers have done in practice. But given the
issue of multi-valued support and wan
> I have tried the 2 authentification manager found in the jasig wiki:
> 1- DirectMapping Authentication manager
> 2- AuthenticationHandler-to-PrincipalResolver AuthenticationManager
>
> Each time only one x509 resolver works.
Because both have the same credential type. You'll need to create two
c
I have tried the 2 authentification manager found in the jasig wiki:
1- DirectMapping Authentication manager
2- AuthenticationHandler-to-PrincipalResolver AuthenticationManager
Each time only one x509 resolver works.
Anybody say if someone have already deploy CAS with two resolvers for x509
aut
12 matches
Mail list logo
