Date: Fri, 29 Mar 2024 15:45:22 +0000 (UTC)
Message-ID: <1953483550.1.1711727122782@6d076f9eb44f>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_0_1362035017.1711727122766"
------=_Part_0_1362035017.1711727122766
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Additio=
nal N-Tier / Proxy / Delegation Support
Shibboleth currently implements protocols and profiles that address auth=
entication of a user relying on a browser. From the begining of the project=
, however, there has been interest in SAML's relevance to n-tier use cases.=
When an SP receives SAML tokens, what, if anything, can it do with them in=
order to authenticate that user to a backend service? How would it do this=
? There have been several attempts to define approaches to this problem.
An initial work item for this is listed above and is under development.<=
/p>
Generally (but not always), the proposed solutions involve using SAML, o=
r possibly a non-SAML protocol to allow for a request to the IdP for additi=
onal assertions that can remap identities or include new attributes, and th=
en a way to attach the new assertions to whatever protocol the SP is using =
to communicate with the backend service.
- To what degree can the exchange with the IdP be generic, and/or rely on=
a standards-based protocol with marketplace traction?
- What kinds of back-end protocols are of interest and can be supported? =
Is SOAP a dead end at this point in favor of REST? Is using SAML with SOAP =
and WSS viable anyway, allowing for SOAP toolkit limitations?
We are seeking a detailed use case, describing the flow, the protocols t=
hat would be used, and the toolkits that would be used in the SP and in the=
backend service to implement this functionality. (This area has not mature=
d to the point where the toolkits can be separated from the protocol stack =
implementations.)
Some possible use case outlines follow.
- Transferring Kerberos tickets from an IdP as attributes=20
- One approach that has been suggested to the delegated credentials probl=
em is to pass forwardable or proxiable Kerberos tickets to the mi=
d-tier SP as SAML attributes. This approach would likely only be usable=
within a domain; cross-domain Kerberos has yet to take hold in the marketp=
lace.
- A simple implementation, without any policy constraints, might be strai=
ghtforward. With the 2.1 IdP, Kerberos tickets are now available within the=
attribute resolver when Kerberos authentication is used. However, the cons=
ensus is that a deployable implementation would require significant policy =
and configuration work in both the IdP and the SP.
- We seek specific, detailed use cases that spell out the policy requirem=
ents in each component. (See KAML email list; see recent email thread; see =
previous discussion on the shibboleth-users email list with Russ Alberry)=
li>
- Information Card support for active clients=20
- The Information Card profiles include features designed for clients or =
servers with more capability than a browser.
- The IdP's support for Information Cards would need to be more full-feat=
ured than the basic support needed for Web SSO, with more advanced WS-Secur=
ity and WS-Trust features.
- The resulting assertions would still need to be attached in an applicat=
ion-specific way, requiring tooling support, but Microsoft claims to have d=
eveloped .NET libraries for leveraging all of this. Is that enough to motiv=
ate it?
- OAuth=20
- OAuth seems to be getting some traction, and may contain a number of in=
teresting pieces that are relevant, either alone, or along with supporting =
oAuth itself.
- Figuring out whether the IdP can play a role with an unmodified use of =
OAuth is important.
- A SAML adaptation of OAuth may be worth looking at as well.
- A highly simplified SOAP interface to the IdP to obtain assertions=20
- Building something extremely bare-bones, relying on TLS or basic authen=
tication, and a simple GET operation would be simple, and require developin=
g some amount of policy control that would be needed for most of the more c=
omplex approaches.
------=_Part_0_1362035017.1711727122766--