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] delegation/intermediaries solution bullets


> One approach is to profile the simple passing along of a browser-profile
> SSO assertion by an intermediate to a backend.  In many cases this will be
> sufficient based on the trust relationship between the two.  The main
> change required to make this work well is a change that I think has been
> suggested for other reasons:  to make the interpretation of freshness of
> the SSO assertion be based not on validity period (ie, NotBefore and
> NotOnOrAfter conditions) but on IssueInstant and the relying party's
> acceptable time limits after that.

I would add to this considerations like:

- do those two entities share a name for the principal? If not, the
assertion must be exchanged for a new one with a (probably encrypted) name
known by the back-end. Or perhaps a set of attributes directly in the new
assertion.

- supporting the exchange of the bearer assertion for a holder of key
assertion if the intermediary shares a key with the SAML authority, while
the original client did not, allowing a weaker trust relationship between
the intermediary and back-end.

- and lastly, simply having controls on the ability to forward or exchange
the original assertion, perhaps involving Audience conditions

-- Scott



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