idpv3.x user password as attribute

[Cantor, Scott]

On 3/18/15, 11:06 AM, "Raffael Sahli" <sahli at gyselroth.com> wrote:
>was able to release the user password as attribute with 2.4.x.
>
>By enabling the following option in src/main/webapp/WEB-INF/web.xml:
>retainSubjectsPrivateCredentials = true

I wasn't aware of that feature, so no, it's not in V3. None of the built-in flows currently store the password as a private credential of the Subject. The password flow could do that with an enhancement, or it can be copied and customized by somebody to do that.

>"retainSubjectsPrivateCredentials" seems gone in 3.x web.xml and with 
>the scripted attribute only, I get the following error:
>[edu.internet2.middleware.shibboleth.common.attribute.provider.V2SAMLProfileRequestContext:911] 
>- AttributeDefinition: 'password' called unsupported method getUserSession
>
>But there is a compatibility v2 description for requestContext which 
>says "requestContext" does include all v2 methods (including 
>getUserSession?)
>(https://wiki.shibboleth.net/confluence/display/IDP30/ScriptedAttributeDefinition#ScriptedAttributeDefinition-V2Compatibility)

Rod would have to address that question, maybe an oversight. But I don't think that we would allow for that to return a non-null value on the back channel. That idea never worked well and leads to inconsistent behavior. For front-channel cases, it probably could be done.

>I see a lot of changes within 3.x, is it still possible
>to release the user password with idp 3.x?

Not out of the box, no. The getUserSession() method actually being missing may be a bug.

-- Scott