OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]