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: I: [security-services] Token correlation (Nate's summary)


I think can be useful to post the following conversation with Thinh, it can help to clarify.

Federico


-----Messaggio originale-----
Da: Rossini Federico
Inviato: giovedì 15 luglio 2010 17.36
A: 'Nguyenphu, Thinh (NSN - US/Irving)'
Oggetto: R: [security-services] Token correlation (Nate's summary)

Hello Thinh

I'm not sure if I have understood your question and I try to summarize the scenario you suggest:

The actors are:
the requestors who initiate the business transaction (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 access to SP1 services, the SAML subject is always INT,
in every access to SP2 services, the SAML subject is always INT,
..
in every access to SPm services, the SAML subject is always INT,

In this situation, what is then the advantage of using the SAML assertion?
Wouldn't it be much simpler, if you configure the SP to accept every request from the intermediary INT without using the SAML assertion?

In my opinion, each SP will need to know the following:
which business transaction invoked the service,
who the real requestor is,
when the IDP issued the token to authorize the transaction execution.

Therefore, to produce this information, the intermediary will need to carry the token defined for the original requestor (C1, C2, .Cn)


-----Messaggio originale-----
Da: Nguyenphu, Thinh (NSN - US/Irving) [mailto:thinh.nguyenphu@nsn.com]
Inviato: martedì 13 luglio 2010 20.44
Cc: Rossini Federico
Oggetto: RE: [security-services] Token correlation (Nate's summary)


 Hello Federico,

Would you please clarify your proposal of why SAML-X needs to bundle in
SAML-Y.  Why can't the IDP reissue a new token?

Thinh

-----Original Message-----
From: ext Thomas Hardjono [mailto:hardjono@MIT.EDU]
Sent: Tuesday, July 13, 2010 12:35 PM
To: OASIS SSTC
Cc: Rossini Federico (federico.rossini@telecomitalia.it);
ndk@internet2.edu; Thomas Hardjono
Subject: [security-services] Token correlation (Nate's summary)

Federico,

Thank you for presenting your work today to the SSTC.  We would like to
hear regular updates about it.

Here is Nate's summary in today's SSTC call:

- The Token Correlation proposal makes sense.
- Use the Condition element.  There are at least 2 choices
  for linking assertion SAML-X with SAML-Y:
  (a) Put a pointer (to SAML-X) inside SAML-Y, or
  (b) Put the entire SAML-X assertion inside SAML-Y.
- Better (preferred) if both SAML-X and SAML-Y assertions
  are valid when they reach the Service provider.

Nate, did I miss anything?

/thomas/


__________________________________________



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]