On closer review, I was also incorrect in my characterization of the extent to which encrypting SAML assertions is adopted: encrypting assertions of identity is turned on by default in the Shibboleth IdP and is well supported in the Shibboleth SP, and because this is the default, it is adopted. It's encrypting of authentication requests, not identity assertions, that is not widely adopted.
Which leads me to believe that, circling back to Michael's original question, introducing a Shibboleth IdP and relying upon it as the solution for identity assertions that can only be consumed by the intended audience, and integrating the desired applications via the Shibboleth SP software, is a promising architecture to meet Michael's requirements. > Shibboleth in principle can handle this by encrypting the SAML assertion with the relying party's public key so that only the holder of the private key, the relying party, can decrypt it. If my initial use cases for services needing to obtain attributes JIT that ought not to be released to end users were narrow enough, I might start there, introducing a Shibboleth IdP for use with my CAS server and preferring it as the feature-rich engine for attribute marshalling, transformation, and JIT release via encryted SAML assertions. I should immediately temper the enthusiasm of the signed SAML assertions idea, though, with the recognition that encrypting SAML assertions is not widely adopted and my impression is it's not supported as widely as would be desirable. Still, it's a formal and rigorous way to accomplish this. On Wed, Mar 20, 2013 at 11:32 AM, Andrew Petro <[email protected]> wrote: > A try to clarify some issues raised in this thread generally, and then I > get down to some ideas for addressing Michael's requirements specifically: > > Service tickets are bearer tokens authenticating the end user. They do > not authenticate services, applications, or anyone else. These bearer > tokens are borne by the end user and by the application the end user > presents them to attempting to log in to it. > > When you configure CAS to release attributes in exchange for a service > ticket, then you are configuring CAS to release attributes in exchange for > a token that authenticates only the end user. > > If the bearer of a bearer token is compromised by the Adversary, then the > Adversary gains access to the borne tokens and, because they are bearer > tokens, can make use of them with impunity. > > So, here, if the user agent is hacked, the Adversary can lay hands on the > service tickets the user acquires (or capture the user's password and then > acquire any other service tickets he likes) and can take those service > tickets and validate them himself, harvesting all the user attributes they > yield. > > This is not a security defect in CAS as such. It's just the nature of the > security model, of the design. Service tickers are bearer tokens. They > have these characteristics. > > CAS adopters should configure CAS to release only user attributes that > they are willing to release under this security model (or enhance CAS to > change the security model). That is, only release attributes you're > willing to release to the end user's user agent, which, sure, like all > things in life, might be compromised. Or the end user might have given up > his password in a phishing attack. Or shared it with his significant other > with whom he's now had a nasty breakup. You get the idea. End user > authentication is a horribly messy thing, and service tickets are only > obtained by end user authentication, not by authentication of anything > else. Bearer tokens authenticating the end user. > > Proxy Granting Tickets have different security properties. A service must > authenticate itself (via an https callback mechanism) to obtain a PGT, and > a PGT authenticates that service in the context of its participation in the > end user's single sign-on session. > > So. If you want to add authentication of the service doing the ticket > validation, that's a fine thing to add. I see it as on this roadmap: > > https://wiki.jasig.org/x/OwE_Aw > > and it would simplify aspects of CAS. The PGT callback would be > unnecessary, since the PGT could be included directly in the validation > response. ClearPass would be unnecessary, since the password could be > included directly as an attribute in the validation response. > > It's a fine improvement to make. It amounts to making service tickets no > longer bearer tokens and instead tokens that only the intended relying > party can successfully validate. > > So then there's the question of how to authenticate these services, these > relying parties. Shared secret, with the shared secrets registered in the > service registry, feels like the Simplest Thing That Could Possibly Work. > If I were coding a proof of concept of this, I'd start there. TLS has > potential. > > Shibboleth in principle can handle this by encrypting the SAML assertion > with the relying party's public key so that only the holder of the private > key, the relying party, can decrypt it. If my initial use cases for > services needing to obtain attributes JIT that ought not to be released to > end users were narrow enough, I might start there, introducing a Shibboleth > IdP for use with my CAS server and preferring it as the feature-rich engine > for attribute marshalling, transformation, and JIT release via encryted > SAML assertions. I should immediately temper the enthusiasm of the > signed SAML assertions idea, though, with the recognition that encrypting > SAML assertions is not widely adopted and my impression is it's not > supported as widely as would be desirable. Still, it's a formal and > rigorous way to accomplish this. > > I'd also say this: you could invent a new, ClearPass-like CAS server > endpoint, say > > /cas/attributes > > and require applications to present a proxy ticket to authenticate to > that, just as today they present a proxy ticket to authenticate to > ClearPass. The implementation of that endpoint would need to know how to > translate from the authenticated proxy chain to the set of services you'd > like to release, but a naive implementation of treating the last identifier > in the proxy chain as a service identifier and doing the service registry > lookup might well be good enough. > > This would get you to a security model where the token is authenticating > the relying party in the context of the end user's SSO session rather than > just the end user, without inventing any new shared secrets, TLS reliances, > or public key cryptography, and instead leveraging the n-tier > authentication feature already in CAS. > > Hope this helps. > > I do think it wil be worth getting to an updated CAS product, protocol > that does authenticate services doing ticket validation, because while I > don't think the current model is broken -- it's entirely serviceable for > what it does -- I do think a security model where service tickets are not > merely bearer tokens will be even better. > > Andrew > > > > > PS: > > The requirement on the validation call from relying parties to CAS (the > call where they validate a service ticket, as in a call to /samlValidate) > requires presentation of the correct Service identifier to which the > service ticket was intended to authenticate the user *not* because an > Adversary would have any difficulty guessing a correct value for this > parameter, but only to help relying parties not fall prey to illicit > proxies. An illicit proxy would arise if end user A obtains service ticket > to authenticate to application B, presents the ST to B, and instead of > validating the ST, B presents the service ticket to C to attempt to > illicitly log in to C as the end user. C will attempt to validate the > service ticket and the validation will fail because C will use its own > identifier as the service parameter on the validation attempt. Not because > it couldn't have used any other parameter or because it couldn't have > guessed the one matching the service ticket (the namespace is in practice > way too small to make guessing difficult), but because that's not the > question it asks. Presenting the service parameter is in effect asking CAS > "Hey CAS, whom if anyone does this ST authenticate to this service?" CAS > could just as well have included the service identifier associated with the > ST in the validation response, except relying parties might not properly > validate that, just as they sometimes overlook the need to validate proxy > chains. > > > > > > > On Tue, Mar 19, 2013 at 5:32 PM, Michael Easthope < > [email protected]> 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" <[email protected]> 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 [email protected] as: >>> Michael.Easthope+jasig@gmail.**com <michael.easthope%[email protected]> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/**display/JSG/cas-user<http://www.ja-sig.org/wiki/display/JSG/cas-user> >>> >> -- >> 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-user >> >> > -- 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-user
