SAManage with Shibboleth 3?

Tue Apr 17 04:32:25 EDT 2018

Hi Tom,

On 16/04/18 21:03, Tom Scavo wrote:
> On Mon, Apr 16, 2018 at 2:49 PM, Mark Cairney <Mark.Cairney at ed.ac.uk> wrote:
>>
>> From the information I've received from the user:
>>
>> "
>> Hello,
>> This link would show what visible in your instance's metada:
>> https://edin.samanage.com/saml/metadata.  However, as mentioned previously
>> we are looking for the token signing certificate to be included in the saml
>> request as it would be compared with the certificate you have pasted under
>> Setup -> SSO for validity.
>> "
>>
>> Does this make sense to you given they themselves don't provide any
>> certificates for signing/encryption (the metadata file they provided is
>> literally 4 lines of XML!) and the only certificates I'm aware of that are
>> routinely transferred during a SAML conversation are one or more of these?
> 
> No, that doesn't make much sense but let me take a stab at it. Did you
> in fact paste your IdP signing certificate into their web interface as
> they claim? If so, then that's all they should need to verify the
> signature on the response but apparently they want/need more. I
> suppose you'll need to get to the bottom of that. Why do they need
> more than the certificate you pasted into their UI?
>

Yes, I can confirm that the IdP signing certificate has been loaded into
their UI

>> Also at least one piece of the few bits of documentation say to disable
>> encryption and signing?
> 
> XML security goes both ways and you're getting confused (which is
> contributing to the overall confusion). The SP does not have a
> certificate in its metadata so the SP does not support outbound
> signing nor inbound encryption. You OTOH MUST support outbound signing
> so I assume you have a signing certificate in your metadata, right?
> That's the same certificate you apparently pasted into their UI. Okay
> then, case closed :-)
> 

Yes, I do. I must admit I'm starting to question my own knowledge/sanity
hence the confusion. It's a bit unusual (although I can't think of any
technical reason why it wouldn't be possible) to have only one party
signing it's assertions and/or response though.

>> I was under the impression that signing/encryption had to be mutually
>> declared between both parties?
> 
> No, I don't know what you mean. The only thing that's absolutely for
> sure is that the IdP signs the response, so you have to provide them
> with your trusted signing certificate. That's it. Nothing else is
> strictly required in either direction.
> 

That's what I thought however looking at the SAML trace I can't see any
signing being done:

<samlp:AuthnRequest
AssertionConsumerServiceURL='https://desk.ei.ed.ac.uk/saml/edin'

Destination='https://idp-test.ucs.ed.ac.uk/idp/profile/SAML2/Redirect/SSO'
                    ID='_73dabdfc-d84f-45ec-8a2a-01c5b3338133'
                    IssueInstant='2018-04-17T08:14:56Z'
                    Version='2.0'
                    xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
                    xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'>
  <saml:Issuer>SAManage.com</saml:Issuer>
  <samlp:NameIDPolicy AllowCreate='true'

Format='urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
/></samlp:AuthnRequest>

<samlp:AuthnRequest
AssertionConsumerServiceURL='https://desk.ei.ed.ac.uk/saml/edin'

Destination='https://idp-test.ucs.ed.ac.uk/idp/profile/SAML2/Redirect/SSO'
                    ID='_73dabdfc-d84f-45ec-8a2a-01c5b3338133'
                    IssueInstant='2018-04-17T08:14:56Z'
                    Version='2.0'
                    xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
                    xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'>
  <saml:Issuer>SAManage.com</saml:Issuer>
  <samlp:NameIDPolicy AllowCreate='true'

Format='urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'
/></samlp:AuthnRequest>

And the debug logs mention things not being signed in several places:
2018-04-17 09:15:02,936 - DEBUG
[org.opensaml.saml.saml2.binding.security.impl.SAML2AuthnRequestsSignedSecurityHandler:80]
- [129.215.243.72]|SPSSODescriptor for entity ID 'SAManage.com' does not
require AuthnRequests to be signed

2018-04-17 09:15:02,969 - DEBUG
[org.opensaml.saml.common.profile.impl.PopulateSignatureSigningParameters:187]
- [129.215.243.72]|Profile Action PopulateSignatureSigningParameters:
Signing not enabled
2018-04-17 09:15:02,972 - DEBUG
[org.opensaml.saml.common.profile.impl.PopulateSignatureSigningParameters:187]
- [129.215.243.72]|Profile Action PopulateSignatureSigningParameters:
Signing not enabled
2018-04-17 09:15:02,973 - DEBUG
[net.shibboleth.idp.saml.saml2.profile.impl.PopulateEncryptionParameters:299]
- [129.215.243.72]|Profile Action PopulateEncryptionParameters: No
encryption requested, nothing to do
2018-04-17 09:15:03,471 - DEBUG
[org.opensaml.saml.saml2.profile.impl.AbstractEn
cryptAction:183] - [129.215.243.72]|Profile Action EncryptNameIDs: No
encryption
 parameters, nothing to do
2018-04-17 09:15:03,472 - DEBUG
[org.opensaml.saml.saml2.profile.impl.AbstractEn
cryptAction:183] - [129.215.243.72]|Profile Action EncryptAttributes: No
encrypt
ion parameters, nothing to do
2018-04-17 09:15:03,473 - DEBUG
[org.opensaml.saml.common.profile.impl.SignAssertions:146] -
[129.215.243.72]|Profile Action SignAssertions: Will not sign assertions
because no security parameters context is available
2018-04-17 09:15:03,473 - DEBUG
[org.opensaml.saml.saml2.profile.impl.AbstractEncryptAction:183] -
[129.215.243.72]|Profile Action EncryptAssertions: No encryption
parameters, nothing to do
2018-04-17 09:15:03,478 - DEBUG
[org.opensaml.saml.common.binding.impl.SAMLOutboundDestinationHandler:62]
- [129.215.243.72]|Adding destination to outbound SAML 2 protocol
message: https://desk.ei.ed.ac.uk/saml/edin
2018-04-17 09:15:03,478 - DEBUG
[org.opensaml.saml.common.binding.security.impl.EndpointURLSchemeSecurityHandler:52]
- [129.215.243.72]|Message Handler:  Checking outbound endpoint for
allowed URL scheme: https://desk.ei.ed.ac.uk/saml/edin
2018-04-17 09:15:03,479 - DEBUG
[org.opensaml.saml.common.binding.security.impl.SAMLOutboundProtocolMessageSigningHandler:85]
- [129.215.243.72]|Message Handler:  Message context did not contain
signing parameters, outbound message will not be signed

> Hope this helps,
> 
> Tom
> 
>> On 16/04/18 17:01, Peter Schober wrote:
>>
>> * Mark Cairney <Mark.Cairney at ed.ac.uk> [2018-04-16 15:47]:
>>
>> The docs I've been following are:
>> https://community.samanage.com/message/6116
>> and
>> https://wiki.shibboleth.net/confluence/display/SHIB2/SAManage
>>
>> From those two I gather that your question actually is:
>> How do I release the subject's email address as an emailAddress-format
>> NameID in Shibboleth IDPv3?
>>
>> relying-party.xml:
>>      <bean parent="RelyingPartyByName" c:relyingPartyIds="SAManage.com">
>>         <property name="profileConfigurations">
>>             <list>
>>               <bean parent="SAML2.SSO" p:encryptAssertions="never"
>> p:signAssertions="always" p:encryptNameIDs="never"
>> p:signResponses="always"
>> p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
>>             </list>
>>         </property>
>>     </bean>
>>
>> FYI, you can drop p:nameIDFormatPrecedence from there and instead
>> simply add that format as the first (or only) NameIDFormat element to
>> the locally-managed SAML metadata you load from
>> %{idp.home}/metadata/samanage-metadata.xml
>>
>> attribute-resolver.xml:
>>
>> No need to touch the resolver for IDPv3. Instead just add this to your
>> conf/saml-nameid.xml (and remove your previous attempts while you#re
>> there) to the util:list with id="shibboleth.SAML2NameIDGenerators":
>>
>>   <!-- email as NameID -->
>>   <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>>       p:omitQualifiers="true"
>>       p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
>>       p:attributeSourceIds="#{ {'mail'} }" />
>>
>> and release the 'mail' attribute to the SP in your
>> attribute-filter.xml, as usual.
>>
>> Done.
>>
>> -peter
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>> --
>> For Consortium Member technical support, see
>> https://wiki.shibboleth.net/confluence/x/coFAAg
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net

-- 
/****************************

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: Mark.Cairney at ed.ac.uk
PGP: 0x435A9621

*******************************/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.