This method is used in :
- AbstractNonInteractiveCredentialsAction
- AuthenticationViaFormAction
- TicketGrantingTicketResource (REST API).
I believe it's also called (perhaps indirectly) when the registry
cleaner expires orphaned tickets, though many deployers disable that
functionality since it can cause some systems to be flooded with
requests since tickets may be expired in large batches.
Is this the expected behaviour (performing a back channel SLO) ? I
think so...
That's correct.
How can a perform a front channel SLO here ? Or will the front
channel SLO only available when calling the /logout url ?
I assumed it would only occur when calling /logout. Since front-channel
is fundamentally driven by a user agent, it seems like a reasonable
requirement.
2) Question : HTTP caching
The LogoutController class is based on the AbstractController class with a
setCache(0) call in the constructor. It means that the appropriate headers are
added on the logout page or redirection to prevent caching.
I plan to keep this behaviour.
Seems correct to me.
3) Question : SAML messages compression You use a deflater to
compress the SAML messages sent for front SLO. Is it really necessary
? It means that the CAS client will need to evolve to deal with it,
right ?
The XML message needs be encoded some way that accommodates a URL query
parameter, and DEFLATE encoding fits the bill. The implementation I
wrote was straight from the section "3.4.4.1 DEFLATE Encoding" in
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf.
Clients would obviously need a symmetric decoding routine to handle
this, and I had imagined it would be added to clients over time since
this is new functionality that is optional.
Is this compression mandatory or just an optimization ?
It's required for DEFLATE encoding, but it's simply the default
encoding. Here's what the spec says:
Binding endpoints SHOULD indicate which encodings they support using
metadata, when appropriate. Particular encodings MUST be uniquely
identified with a URI when defined. It is not a requirement that all
possible SAML messages be encodable with a particular set of rules, but
the rules MUST clearly indicate which messages or content can or cannot
be so encoded. A URL encoding MUST place the message entirely within the
URL query string, and MUST reserve the rest of the URL for the endpoint
of the message recipient. A query string parameter named SAMLEncoding is
reserved to identify the encoding mechanism used. If this parameter is
omitted, then the value is assumed to be
urn:oasis:names:tc:SAML:2.0:bindings:URL-Encoding:DEFLATE.
This says to me we can invent an encoding without compression and give
it a name that is conveyed in the SAMLEncoding parameter. I would think
anything that is base64-encoded would be compliant with URL encoding, so
we could do a one-off of DEFLATE that simply encodes the XML DOM as text
to base64. That said, I think it's generally preferable to use existing
standards where possible.
Should we also compress SAML messages for the back channel SLO ?
Possibly as a future (optional) optimization, but I see no need to do
that now.
M
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
