Shibboleth Developers

["Scott Cantor" <>]

> Hmm, I'm not so sure.  NameIDMappingRequest is intended for use by SPs
> that already possess a NameID for the principal in question, so the
> old NameID must be included in the request.  In other words, the Name
> Identifier Mapping Protocol assumes an act of authentication has
> already occurred.  In our case, the act of authentication occurs at
> the time of request.

No, it assumes nothing about authentication. It assumes you have a NameID,
and that's about all. If you're not planning on using SAML for
authentication to MyProxy, then you must think you have a NameID already to
do an AuthenticationQuery. If so, you could use something like the
NameIDMapping protocol to turn that something into a DN, for example.

> Well, authn assertions have <saml:Conditions> elements, which we sorta
> need in this case since the lifetime of the name identifier must match
> the lifetime of the proxy cert.  [SAML2Prof] encourages this, in fact:

The AA can enforce the lifetime the same way it does with transients now,
internally. The real extension is that you'd need a way to even indicate to
the AA what the lifetime should be in the first place.

> This is not possible in SAML 1.1, however, since the <saml:Subject>
> element is tied up in the statement.  Also, it's not at all clear how
> the desired lifetime should be communicated to the IdP.

Correct. This isn't possible with any of these variants. It's sort of
possible with an AuthnRequest, but that's all the way into SAML 2.0.

I just think this is all a bad fit. I think the SAML authority should be
issuing the certificates. Nothing else makes a great deal of sense to me.
But if you split them up, then I think they need to communicate behind the
scenes, whether it's with encryption or whatever else. It just happens that
the encryption idea is known to work and there's already examples like
LionShare doing it.

-- Scott