Hi, I really appreciate the feedback. I didn't know that the proxy mechanism could be used so heavily by clients.
I'm not sure to understand your last sentence : about the client certs used for proxy, does it mean that these are defined on the truststore on the CAS server side ? We are somehow back to the discussion with the "burdeon of the certs management", highlighted previously by Marvin. I'm thinking more and more that this certificates management is one of the key question. On one hand, we can define default certification entities likes Verisign in the key store and we won't have to manage each application certificate but at the same time, an attacker can easily create a valid certificate (trusted). On the other hand, we can define empty key/trust stores and it will require work to manage all the accepted certificates, but this time any check on certificate is very valuable (as no attacker can forge easily a valid certificate). Best regards, Jérôme 2013/9/10 William G. Thompson, Jr. <wgt...@gmail.com> > Way back in the day when CAS protocol was developed there was no > notion of a CAS Services Registry. This was to make it as easy as > possible for CAS clients to bootstrap into the SSO domain. Fast > forward about a dozen years, and every enterprise-wide deployment I'm > aware of is running some version of the Services Registry. The > Services Registry itself has grown over the years and we now have > whitelist, attribute release policy, login screen customization, > course-grained authorization, etc. CAS Services, for better or worse, > almost always have some level of "metadata" already, so the idea of > adding/managing a public key for the service doesn't seem too far of a > stretch. > > Relatedly...Unicon has had a couple of clients that made heavy use of > proxy tickets as the basis for enterprise-wide SOA deployment. These > folks utilized client certs as the mechanism to authenticated the > client to reduce the proxy callback overhead, as well as the means for > authenticating services themselves in person-not-present scenarios. > > Best, > Bill > > > On Fri, Sep 6, 2013 at 12:13 PM, Jérôme LELEU <lel...@gmail.com> wrote: > > I understand your point of view. > > > > The DNS attack we are trying to mitigate with this protection is very > > unlikely. So this extra check should not be enabled by default, but maybe > > only for some very few super critical services. That way, the burdeon of > > certificates management would not be a real issue. > > > > Thus, I tend to think that having the same check than for proxy callback > > would be good for (code) consistency ! > > > > For this proposal (SEC_6), I noticed also that it doesn't make sense to > have > > it if we don't have SEC_5 : if we have a default truststore (a lot of > > certificates are consequently trusted), so a certificate check is not > very > > useful. > > And if we don't have SEC_5, SEC_4 becomes more useful : if we have a > default > > truststore (a lot of certificates are consequently trusted), an url > check on > > the proxy callback url is more useful. > > > > I hope things are getting clearer... > > > > > > > > 2013/9/6 Marvin S. Addison <marvin.addi...@gmail.com> > >>> > >>> why can't we just > >>> import the certificate of the client application for a SSL check from > >>> the CAS server to the client application ? To avoid of course that the > >>> CAS server trusts all certificates certified by Verisign or another > >>> certification entity... > >> > >> > >> That would be an acceptable solution with respect to security. From an > >> operational standpoint, it seems as untenable as managing keys for each > >> peer. The vast majority of certificates expire annually or biannually, > which > >> would require substantial communication and maintenance costs for a > >> non-trivial deployment. In practice no one does certificate trust on a > >> per-certificate basis for this reason. > >> > >> You might consider a facility like Shibboleth metadata where each > service > >> is responsible for maintaining its own certificate or other data needed > to > >> provide strong identity assurance. That scales much better by > distributing > >> the maintenance burden among N peers. On balance it's probably more work > >> than what would be feasible for the 4.0 release. > >> > >> > >> M > >> > >> -- > >> You are currently subscribed to cas-dev@lists.jasig.org as: > >> lel...@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: > 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: > lel...@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
