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: [no subject]

Obviously one concern is privacy of subject names.  In the simple
pass-along case the intermediate and backend must share (and be permitted
to share) the understanding about the username (and any other user
attributes).  The trade-in approach permits the intermediate and backend
to be in different privacy domains.

> As described, this would be simple impersonation. If we wanted to do a
> bit more work, delegation could be introduced to expose both the
> identity of the principal and of the proxying SP. Related to this, we
> might want to standardize a control condition to limit the repeating of
> this exchange process (preventing it from hopping back another link from
> the new SP).

I respectfully submit that completion of a more full-fledged delegation
scheme is not likely to make our agreed-on SAML 2.0 ship date.

> 3. SSO with stronger SubjectConfirmation

Well, my doc limited the discussion to scenarios based on current browser
profiles.  I have the same reservations about supporting enhanced-security
delegation based on better-than-bearer SSO that I do about other more
complicated aspects of this (ie, time to finish).  I'd like to think that
elaborations of the token-exchange mechanism to support this can be
layered on later.

> 4. Non-SAML tokens delivered during SSO or AttributeQuery
> RL Bob's second bullet I think can be addressed by standardizing the
> carriage of some token formats as SAML attributes, base64 encoded in
> some cases, obviously. But we should pick standardized names for
> Kerberos tickets and the like. I don't know enough technical detail
> about Kerberos at the lowest level to know exactly how this will work,
> or what exactly has to be passed in the attribute to permit an SP to
> authenticate to a Kerberized service.

I think we should proceed with this approach, with the goal of profiling
Kerberos specifically.  It would be good to have this work consistently
whether the additional tokens are delivered as part of SSO or via later
request from the intermediate.

 - RL "Bob"

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