Cherwell application (on-prem)

[Lohr, Donald]

PS, we found an existing Cherwell ticket with that *InvalidNameIDPolicy 
*error that we’re seeing. It /indicates that the “Type of ID” should be 
looked at://
//
//Note: This ID needs to match the ID the SAML provider is sending back 
to us//
//
//If Cherwell has the correct ID type, have the Identity Provider (ADFS, 
Shibboleth, etc) check the ID they are sending to us. //
///

  * /Windows Login = Kerberos Principal Name (i.e. DOMAIN\username) or
    the SAMAccountName/
  * /E-mail address = E-mail address with domain (i.e. username at domain.com)/


This is my our attribute-resolver.xml & attribute-filter.xml files have 
what I listed below.  Or our stab at what we believe.

DL

On 4/26/19 4:55 PM, Lohr, Donald wrote:
> Not wanting to share too much specific data, which was why I mentioned 
> off-line.
>
> We are not specifically wanting to Shib the thick client, but the 
> portal.  We are not choosing the email address, but Windows Login (not 
> using email is a long story in and of itself).  In the SP metadata is:
>
> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
> <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:*nameid-format:kerberos*</md:NameIDFormat>
>
> Attempting to follow two different on-line Cherwell documents (public) 
> we guessed and put the following in our respected IdP files:
>
> attribute-resolver.xml
> <resolver:AttributeDefinition id="sAMAccountName" xsi:type="ad:Simple" 
> sourceAttributeID="cn">
>     <resolver:Dependency ref="oud" />
>     <resolver:AttributeEncoder xsi:type="enc:SAML2String" 
> nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" 
> name="sAMAccountName" encodeType="false" />
> </resolver:AttributeDefinition>
>
> attribute-filter.xml
> <afp:AttributeFilterPolicy id="cherwellportal">
>         <afp:PolicyRequirementRule 
> xsi:type="basic:AttributeRequesterString" 
> value="https://xxxx.sss.ccc/CherwellClient"/>
>         <afp:AttributeRule attributeID="sAMAccountName">
>                 <afp:PermitValueRule xsi:type="basic:ANY" />
>         </afp:AttributeRule>
> </afp:AttributeFilterPolicy>
>
> But we get the following error at login:
>
> *SAML Auth failed: An error occured, SAML status codes: 
> urn:oasis:names:tc:SAML:2.0:status:Requestor, 
> urn:oassis:names:tc:SAML:2.0:status:InvalidNameIDPolicy *
> We are running Cherwell v9.3.5.x and our Shib IdP is v3.3.3. Our Shib 
> IdP is back by a non-AD LDAP directory.
>
> There online docs do not seem to use Shib 3.x speak in their examples.
>
> Thx,
> DL
>
> On 4/26/19 4:18 PM, Cantor, Scott wrote:
>> I did a quick review. It's almost vanilla, I'm sending it a NameID in emailAddress format. It had a key and supports encryption. It didn't used to support SHA-2 signatures, but does now. The non-vanilla bit was that I was never able to get it to accept signed responses alone (it claims to, but it didn't work last I tested), so I had to toggle the metadata for it to trigger assertion signing, and that was about all.
>>
>> -- Scott
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190426/5346204c/attachment.html>