Neocase HR and portal apps?

[Mark K. Miller]

On Tue, 16 Aug 2016, Cantor, Scott wrote:

> On 8/15/16 9:15 PM, Mark K. Miller wrote:
>>
>> I have my IdP running in v2 legacy mode.  Could you provide a pointer to
>> directions/example for doing SHA-1 with a specific SP?
>
> Can't. All or nothing.

I was afraid of that!  Let try to be exactly clear what you're saying 
here.  Am I correct in thinking it's "all or nothing" only in legacy mode, 
but new v3 configs allow this to be controlled on a per SP basis?

And, given that question, in your first message when you said "(easy to 
test)" were you referring only to native v3 configs, or is there something 
for me to try that I'm just not grasping?

> You can set up a copy for testing.

I made an attempt to try this last night...

>                                    But I don't think the global property
> that switches it to SHA-1 works in legacy mode either unfortunately,
> unless I'm misremembering.

Indications are you're remembering exactly correctly.  So, rather than 
'all or nothing,' it's really just "all."  ;-)

I tried a change in the idp.properties file.  Right after this comment:

# To default to SHA-1, set to shibboleth.SigningConfiguration.SHA1
#idp.signing.config = shibboleth.SigningConfiguration.SHA256

I added a line like this:

idp.signing.config = shibboleth.SigningConfiguration.SHA1

Is that supposed to be the way to change this, or would this be done some 
other way?

The SP continued to fail in the same way.  And, if I was looking at the 
right stuff in the SAML tracer, things appeared to still be SHA256.

> For an updated configuration there are specific examples in the wiki for
> controlling this by SP.

Yeah, I thought that's what I was seeing.  And this confirms the 
difference between legacy and native configs I was trying to be clear 
about above.

>> So, that fits your description.  In this case, though, the parenthetical
>> makes complete sense!  I removed encodeType="false" from the encoders
>> and gave it a try.  It failed just the same as before.
>
> Not surprising, just something to rule out. SHA-2 is more likely to
> break something.

So, can you 'coach me' on what to tell a vendor who wrote their own SP 
about what needs fixed to make this work again?

> -- Scott

Thanks,

Max