[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - SAML V2.0 Profile for Token Correlation (sstc-saml-token correlation-profile-v0.13.pdf) uploaded
> The actors are: > the requestors who initiate the business transactions (C1, C2, .., Cn), the > intermediary (INT) (only 1), the > service providers (SP1, SP2, .., SPm). > The transactions are executed via the intermediary INT. On behalf of the requestors. You have to start by recognizing the security semantics. If this really isn't delegation, then you shouldn't need any notion of the requestor in the transaction, or it could simply be expressed as application data ("perform this action for INT on C1's data"). Using an invalid or expired assertion to represent the actor C1 amounts to expressing C1 as application data because it has no security relevance. > Moreover, each SP will need to know which business transaction invoked the > service, who the real requestor is, If the "real requestor" has to be known, it can be "known" in two ways: securely and as asserted data by INT with no valid proof. Your approach seems to be the latter and I disagree with using SAML to represent that (note, I don't necessarily disagree with using a SAML <NameID> to represent that). My approach is to represent it securely and with the right policy controls in place (where the policies are of course totally up to the deployer). > To produce this information, the intermediary will need to carry the token > defined for the original requestor (C1, C2,...Cn) It needs a token that represents all of the necessary information securely, and *validly*. The token issued to the original requestor likely has nothing to do with the transaction invoked by INT, it may be expired, have an audience and subject confirmation that precludes its use by INT, etc. These are all problems with your design. > If you use the DelegationRestriction condition as is, and issue the > intermediary's assertion with the end user's NameID in the subject and the > intermediary in the delegation condition; the Idp will issue > an assertion for C1 with INT in the delegation condition (SAML <C1, INT>) > an assertion for C2 and INT (SAML <C2, INT>) > and so on.. (SAML<Cn, INT>). That's delegation, yes. Note that "the IdP" may not be the same IdP that issued the original assertion to C1 or C2. That's a deployment decision. > In this scenario, the Idp will issue all the SAML assertions in a "static > way", so the INT will have all the SAMLs to access to every Service > Provider. I don't know what you mean by "static". It can be totally dynamic. It's simply the STS model. You exchange one token for another when you need to do so. You can do it with WS-Trust or SAML or OAuth or probably ten other mechanisms, but it's the same idea. > Now my objection is: > what is the difference between the pattern above and authorizing directly > INT to access to every service? Because the ability to acquire a delegation token is entirely subject to policy, and what proof the STS/etc. requires. That proof can be significant (like using the original token), or it could be a null proof (in which INT can freely obtain them). > If I well understood in the delegation profile, if the IDP wants to issue a > new token as consequence of a previous request, the "original token MUST > carry appropriate SubjectConfirmation to allow the intermediary to use it", > that means that the entire business transaction has to be configured on the > Idp, that means that if something in the application changes, and that > happens very often in context like a telecom company, the administrators > have to re-configure all the security policies. No, that is not true. That is one way of doing things, there are many others. The delegation "profile" is not a complete profile, it's an extension that represents the delegation act in a SAML assertion. It is NOT a method for specifying how one obtains a delegation token, that part is separate, and would depend on the specific needs of the use case. As for where you have to configure things, if you need policy, it will have to be somewhere, and if an application changes, the policy will change. Where the policy lives is also entirely out of scope, since SAML doesn't address policy management. > The token correlation enables to partition the INT capabilities in a easy > way in situation where the platform vendors don't want or can't customize > the protocol for specific enterprise implementations. Something has to correlate your tokens. If it's done securely, you're doing the same policy evaluation, and if it's not, you have a design problem and somebody needs to say so. That's what I'm doing. > SAML will be totally signed except the route tag <Assertion> and nothing > will be removed from the SAML-Y assertion, my idea was put the <token > correlated> element below the route of the assertion, the intermediary could > add the element and the SAML-X inside it, but if that is not correct, the > intermediary could add the SAML-X without the <token correlated> element, > out of the SAML-Y. I don't understand any of that terminology, but "below" or "outside" essentially means that you're accepting my point that this becomes a non-SAML issue. That leaves you free to ignore my criticisms and opinions, so that may be a good thing from your point of view. Bottom line, SAML-Y cannot be touched after signing, nothing can be removed, added, or changed. > About the SAML-X expiration time validity, my idea is that a SAML-X can be > "validated" also if it is expired, it can be formally correct (for example > it is possible to verify that it was generated by a SAML authority) without > being semantically valid, it is clear what the meaning of the rule is and > that rule can easily be implemented. It's also much more than just the expiration time, I would expect various other validity violations, which means you're distorting the intent of the issuer. You are making the same classic mistake that I see repeated all over, which is taking assertions issued for one purpose and pretending that they can be passed around for some other purpose because it's easier than doing things according to the spec. > Otherwise I ask if it could be possible to add a parameter, as an eval-time- > range and evaluate the SAML-X validity applying the rule NotOnOrAfter+eval- > time-range <= current time, instead of NotOnOrAfter<=current time That's what NotOnOrAfter is already for, and is why I included separate expiration information in the SubjectConfirmationData element. That allows each purpose to be individually valid for different amounts of time. > But if all this is really a problem, we can simply specify that SAML-X has > to be valid (also for the NotOnOrAfter condition) even if that make the > protocol less general. I wouldn't agree with your approach, but as long as the correlation is not violating the rules for evaluating the assertions, I won't object. But I suspect your other requirements (trying to perform the actual correlation after the assertion was signed) will force you in a different direction anyway. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]