Michael, It would be great if you could share a little detailsabout your environment. Are you in Higher Ed? Corp? U.S.? What's the target audience?
Best, Bill On Fri, Mar 22, 2013 at 7:31 PM, Michael Easthope <[email protected]> wrote: > Thanks for the comprehensive thinking and the recommendations. The idea of > encrypting SAML assertions fits well with the rest of our environment. We > will investigate that further and I'll try and update you with our > experiences. > > Michael > > > On Thu, Mar 21, 2013 at 11:46 PM, Andrew Petro <[email protected]> wrote: >> >> 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: >>>>> [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 >>> >>> >> >> -- >> 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 -- 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
