Michael, Great question!
cc'ing cas-dev as this relates to on-going work regarding attribute release in cas protocol. cc'ing newly spun up cas-appsec as this relates to on-going threat modeling work. If you have a compromised user-agent, mobile or otherwise, you likely have more pressing issues to worrying about than attributes leaking out of samlValidate. After all, at that point the user's credentials are available as well as any data or services they might have access to. That said, the issue of how the CAS server authenticates (and authorizes) services is an important one. As you point out, currently none of the "normal" validate endpoints authenticate the calling service. Back in the good ol' days before attributes (and proxy granting tickets), the only thing a malicious validate caller could get its hands on was the principal identifier. When PGTs came on-board (around 2003) for the portal use case, mutual service authentication was added via the SSL callback. Here the CAS server does authenticate (and authorize) the calling service for PGT access. Which is a good thing given the power of the PGT. It is interesting to note that under the current protocol...a malicious portal poses the same attack vector as a comprised user-agent regarding attribute leakage (all the same caveats regarding bigger issues apply of course). Now that attributes are common practice both via samlValidate and the custom (soon to be standard) CAS validate, it probably is time to give service authentication deeper consideration. Service validation would allow one to have more confidence regarding attribute release and potentially would allow us to simplify PGT and ClearPass mechanisms. Best, Bill On Tue, Mar 19, 2013 at 5:32 PM, Michael Easthope <michael.easthope+ja...@gmail.com> wrote: > That's basically it. Remember that the redirect is a request being sent to > the users device. If they are running a malicious app then the app can > choose not to honor that request. > > At that point, the app has all the information it needs to generate a > samlValidate call. There can be SSL between the original site and the > device; and between the device and the cas server - but on the device itself > the information is not protected. > > The service registry doesn't help because from the point of view of the cas > server, everything looks normal. > > On 20 Mar 2013 03:23, "Andrew Morgan" <mor...@orst.edu> wrote: >> >> On Tue, 19 Mar 2013, Michael Easthope wrote: >> >>> Its an edge case but if you can trick a user into logging in AND you >>> control the http flow (eg if you are running a malicious mobile >>> application >>> that pretends to be a legitimate app) you can intercept the redirect URL >>> that comes back from a successful sign-in. That redirect URL contains >>> both >>> the service URL and the service ticket - with that you can generate a >>> samlValidate request and obtain the user details - something we only want >>> to be releasing to our own applications. >> >> >> Let's see if I understand: >> >> 1. User goes to https://yoursite >> 2. User is redirected to CAS for login >> 3. User authenticates and is redirected back to https://yoursite >> 4. Something executes a Man-In-The-Middle attack to change the redirect to >> https://badsite? >> >> That doesn't make sense because SSL should be preventing MITM attacks. >> >> Or are you saying there is a mobile application (not a browser) that is >> talking to https://yoursite? >> >> Wouldn't the CAS Services Registry matching rules allow you to specify >> which sites are allowed? Or are we talking about a proxying situation? >> >> Andy >> >> -- >> You are currently subscribed to cas-u...@lists.jasig.org as: >> michael.easthope+ja...@gmail.com >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to cas-u...@lists.jasig.org as: > wgt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- 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
