On Mon, Feb 4, 2013 at 4:15 AM, Alexandre DE PELLEGRIN <depelleg...@essec.edu> wrote: > Hi, > > I'm not a specialist in web security but I think that it could be a > mistake to consider CAS server as an identity provider. > You talked about SAML contant but I think that SAML support in CAS is > just a "bonus feature".
I suppose that mostly depends on what you mean by "identity provider" (IdP). In general WebSSO terms I think one could reasonably qualify the server CAS an an IdP. That is the role it plays in the CAS protocol, and it is in fact a SAML IdP when leveraging the support for Google authentication via SAML2. > > If you need to trust service providers, limit your CAS to internal > network and deploy a Shibboleth Idp in front of it. > With this architecture, you will be able to exchange certificates and > create a real trusted federation between you > and external apps. As Shibboleth IdP is client of CAS, you will be > sure that your CAS server will only receive clean requests. > > If you consider that CAS is unsecure, I think that it should be quite > easy to develop a filter like the throttling login filter > (https://wiki.jasig.org/display/CASUM/Throttling+Login+Attempts). I > think it could be a good approach to keep CAS as > simple as possible. CAS/Shib as an Enterprise WebSSO+Federation solution is no doubt a powerful deployment model. However, I think this still mostly leaves open the questions Kevin raised. Even on an "internal network" one may still want to protect the CAS server from potentially dangerous input. The CAS protocol itself is well defined, so it's not much of stretch to think about whitelist http filters. Best, Bill > > Best regards, > Alexandre de Pellegrin > > > 2013/1/31 Sweere, Kevin <kevin.sweere....@gafg.afrl-wrs.hpc.mil>: >> Hello, >> >> To greatly decrease risk to a CAS server, it should only receive clean, safe >> data from external elements. For example, a CAS webSSO receives SAML >> messages created by XYZ.com and sent from untrusted user browsers from >> around the world. It may also receive CRL or OCSP data to check that user's >> PKI. An intermediate filter can stop unwanted, dangerous data before it >> even reaches the CAS's NIC. Less effective but acceptable are filters >> within the CAS server. >> >> Data that is safely usable by CAS must be allowed while everything else >> should be denied. What is the allowable text for incoming messages? >> Formats? Lengths? What filters exist to do this? (Besides the obvious - >> URLs, PPS) >> >> Thanks, Kevin Sweere, Air Force Research Lab >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> depelleg...@essec.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > > -- > Architecte Solutions Innovantes > Groupe ESSEC > Avenue Bernard Hirsch-B.P.50105 > 95021 Cergy-Pontoise Cedex France > Tel : +33.1.34.43.36.36 > Mail : depelleg...@essec.edu > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: wgt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
