On Mon, Jan 21, 2013 at 8:30 AM, jleleu <[email protected]> wrote: > Hi team, > > Back from vacation, I just start working on this ticket.
Welcome back...hope it was enjoyable. > > > I see four "places" where SAML is used in CAS : > 1) for logout, we send SAML requests to client applications > (AbstractWebApplicationService class) > 2) for SAML validation, we produce SAML responses with attributes > (AbstractSaml10ResponseView, Saml10FailureResponseView and > Saml10SuccessResponseView classes) > 3) to accept SAML 1.1 login requests, we do a custom parsing of the SAML > requests and produce SAML responses (SamlArgumentExtractor and SamlService > classes) > 4) same for SAML (2.0) login requests coming from Google > (GoogleAccountsArgumentExtractor and GoogleAccountsService classes). > > We just need the opensaml library for the SAML validation. > > > The question is what should put in the optional SAML module ? > > By default, CAS logout requests to client applications are SAML requests and > the CAS clients can be/are built on this to handle CAS logout requests : it's > the case for the Java client. > So I tend to think that SAML requests for logout should stay in the core as > it's somehow a mandatory feature of the CAS protocol. Not exactly a mandatory feature of the CAS protocol, but doubt it could be removed from the server at this point. It would be nicer if it was off by default. > > For other SAML features (SAML validation + SAML login requests), I think it > makes sense to put them in the optional SAML module : cas-server-support-saml. > > What do you think ? Since Google SAML2 and CAS Attributes SAML1 really are quite different animals, it probably is worth thinking about two separate modules. Perhaps something like this: * cas-server-support-google-saml2 * cas-server-support-attributes-saml1 At the unconference we starting noodling around the idea of pulling the Google SAML2 support out into a separate war protected by a stock CAS client. Think of this as something like CAS/Shib-lite. A similar approach could be used for creating generic SSO link components for other front-channel SSO techniques, while keeping the CAS server core as simple as possible. More on this later... Best, Bill > > Thanks, > Jérôme > > -- > 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 -- 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
