IDP 3.3.2 CAS protocol and alternate CAS username difficulty

[Michael A Grady]

> On Apr 13, 2018, at 3:30 PM, Mak, David <d.mak at northeastern.edu> wrote:
> 
>> Is it actually a feature to control what's in the SAML NameID in whatever non-SAML thing CAS made up? I think the username customization is for general CAS "proper". Do the docs suggest this is possible?
> 
> The docs do indeed suggest this is possible in the documentation https://wiki.shibboleth.net/confluence/display/IDP30/CasProtocolConfiguration#app-switcher at the bottom section titled "Alternate cas:user in the validation response."
> 
> I am making the assumption that the SAML1 NameIdentifier field maps to the cas:user username field, but when I decode the CAS response sent to the service, it is indeed not changed from the default principal name.
> 
>> If the data is passed in the AttributeStatement properly, that may be what its meant to be doing. I say that from a very uninformed look at the code. The non-SAML validation response logic mentions plowing through IdPAttributes and shows it backing off the the principal name in the ticket state, and the SAML case to me seems to just use the ticket state.
> 
> From my even more uninformed look at the code, I do see in the PrepareTicketValidationResponseAction class, where the CAS TicketValidationResponse.userName is set to the new principal value as specified in the relaying party config. I also see, what you're saying (I think) in net.shibboleth.idp.cas.flow.impl.BuildSamlValidationSuccessMessageAction where the principal gets reset to the ticket state.
> 
> I guess I'm just trying to replicate the old Apereo CAS implementation we had where we could override the principal name with another attribute by specifying that such as:
> 
>                        <bean class="org.jasig.cas.services.RegisteredServiceImpl">
>                                <property name="id" value="7" />
>                                <property name="name" value="Student Success" />
>                                <property name="description" value="Student Success" />
>                                <property name="serviceId" value="https://ssc.advisory.com/**" />
>                                <property name="evaluationOrder" value="10000007" />
>                                <property name="usernameAttribute" value="neuedunuid" />
>                                <property name="allowedAttributes">
>                                        <list>
>                                                <value>neuedunuid</value>
>                                        </list>
>                                </property>
>                        </bean>

The only documented way to control the CAS choice for username is what is the Shib wiki, on that cas:username config. If Marvin (implementor of the CAS support in the IdP) doesn't have that impacting the /samlValidate endpoint's response choice of what to use for the NameID, then we really need Marvin to weigh in on what does. And/or if that is a bug/issue, because that config is not impacting the NameID choice.

However, if you are truly sending a SAML1.1 response, then the other thing you could presumably do is switch to the IdP's support for SAML1.1 and not rely on that CAS /samlValidate endpoint for that.  Unless there is something else "CAS specific" you are doing (proxy tickets?) With whom/what service is this integration that is relying on a SAML1.1 response?

--
Michael A. Grady
IAM Architect, Unicon, Inc.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180413/830e2c43/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://shibboleth.net/pipermail/users/attachments/20180413/830e2c43/attachment.sig>