R: [security-services] Groups - SAML V2.0 Profile for TokenCorrelation (sstc-saml-token correlation-profile-v0.13.pdf) uploaded

[Rossini Federico <federico.rossini@telecomitalia.it>]

Referring to the use case previously posted, which I inserted below:

*****************************************************
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.
Suppose that a business transaction is restarted by the intermediary, then the IDP issues a new token
whose <subject> is set to INT and the Service Provider receives a request with a SAML <subject> set to
INT.
As a consequence in every transaction where SP1 has to be accessed, the SAML subject of the
invocation is INT, in every transaction where SP2 has to be accessed, the SAML subject of the
invocation is INT,, .. and so, for every SP invoked, the SAML subject is always INT,
If INT has the grant to access to every SP because there is always a process that pass through INT, this
situation is similar to that in which the SP to accepts every request from the intermediary INT without
using the SAML assertion.
Moreover, each SP will need to know which business transaction invoked the service, who the real
requestor is, when the IDP issued the token to authorize the transaction execution.
To produce this information, the intermediary will need to carry the token defined for the original
requestor (C1, C2,...Cn)
*****************************************************

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>).

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.
Now my objection is:
what is the difference between the pattern above and authorizing directly INT to access to every service?
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.

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.

I try also to reply to the observation on
the technical content of the proposed profile.

Observation reported below:
*********************************************************
I think the proposal is to have a signed condition element reference the subject of the original assertion, but not sign the actual reference to the assertion. That has serious holes for security, and it's impossible to do within an assertion, because a SAML assertion is either totally signed or not signed; you can't add or remove anything to it. What you'd be talking about would be something at the WS-Security or other application layer, not SAML.

This proposal also has the problem that it wants the relying party to "rely" on the original assertion but doesn't want to required that the original assertion be valid. This is just wrong. If the original assertion is invalid, it is not appropriate to honour some kind of correlation requirement to it. It would be very difficult to understand or explain the security properties of such a system
*********************************************************

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.

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.
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
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.

Federico

-----Messaggio originale-----
Da: Scott Cantor [mailto:cantor.2@osu.edu]
Inviato: marted́ 7 settembre 2010 19.52
A: Rossini Federico; security-services@lists.oasis-open.org
Oggetto: RE: [security-services] Groups - SAML V2.0 Profile for Token Correlation (sstc-saml-token correlation-profile-v0.13.pdf) uploaded

Sorry to follow myself up, but it also occurred to me that if one looks at the current proposal, it seems to be:

- embed the end user's identifier (a NameID) into the intermediary's assertion
- add some kind of unsigned reference to a token with that identifier
- present both tokens to the service

Without addressing the question of whether that's good or bad, that is compelling evidence that there is no new SAML work to do. If you wanted to do this, you could 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. You could do this because the token issuer already has to know both identities based on your proposal anyway.

The other two requirement are not the business of SAML. The middle one strikes me as something similar (maybe identical?) to the WSS notion of a "supporting token". It belongs at that layer, and that leaves you free to implement any processing rules you want over how the two assertions are evaluated in combination.

So I'm even more convinced after a second read that it isn't necessary to define anything new in SAML.

-- Scott



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.