Getting PowerFAIDS NetPartner to work with Shibboleth 3

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl

I realize that others have posted a desire to get PowerFAIDS NetPartner SSO working with Shibboleth’s SAML implementation.  In November of 2014, mrahman posted instructions for doing this with Shib 2.4.2, and I recall having this work for me (see http://shibboleth.net/pipermail/users/2014-November/018121.html).  However, I have not had success in implementing NetParter SSO with Shibboleth 3.  Based on my logs (in debug mode), my hangup at present seems to be that “no relying party configurations ae applicable”, even though I have the relying party configured.  Following is my idp-process log:

 

---BEGIN LOG---

2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.CheckMessageVersionHandler' on INBOUND message context

2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'

2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.saml1.binding.impl.SAML1ArtifactRequestIssuerHandler' on INBOUND message context

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLProtocolAndRoleHandler' on INBOUND message context

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler' on INBOUND message context

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLAddAttributeConsumingServiceHandler' on INBOUND message context

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.saml.profile.impl.InitializeRelyingPartyContextFromSAMLPeer:132] - Profile Action InitializeRelyingPartyContextFromSAMLPeer: Attaching RelyingPartyContext based on SAML peer NetPartner

2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:293] - Resolving relying party configuration

...(non relevant lines removed)…

2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:305] - Checking if relying party configuration EntityNames[https://mynetpartnerhost.myuniversity.edu,] is applicable

2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:310] - Relying party configuration EntityNames[https:// mynetpartnerhost. myuniversity.edu,] is not applicable

2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:314] - No relying party configurations are applicable, returning the default configuration shibboleth.DefaultRelyingParty

---END LOG---

 

 

I added the following bean to my relying-party.xml file to use the Spriden ID (from Banner) for NetPartner:

 

---BEGIN BEAN---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="https://mynetpartnerhost.myuniversity.edu">

            <property name="profileConfigurations">

                <list>

                        <bean parent="SAML2.SSO"

                                p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:encryptNameIDs="false"

                                p:encryptAssertions="false"

                        />

                </list>

            </property>

        </bean>

---END BEAN---

 

 

The following is my metadata file for netpartner:

 

---BEGIN METADATA---

<EntityDescriptor entityID="NetPartner"

        xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

        <SPSSODescriptor

            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

        <AssertionConsumerService index="1"

            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

            Location="https://mynetpartnerhost.myuniversity.edu/NetPartnerStudent/Logon.aspx"/>

        </SPSSODescriptor>

</EntityDescriptor>

---END METADATA---

 

 

I can provide additional configurations and/or complete files if helpful.  Any ideas?

 

By the way, if I can get NetPartner working with Shibboleth IdP v3, I will be happy to post results.

 

 

 

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Boyd, Todd M.
According to that metadata, the relying party is "NetPartner", not the URL you listed in the relying-party.xml file.


-Todd

________________________________
From: users <[hidden email]> on behalf of Daudt, Carl <[hidden email]>
Sent: Tuesday, May 8, 2018 3:05:52 PM
To: [hidden email]
Subject: Getting PowerFAIDS NetPartner to work with Shibboleth 3

I realize that others have posted a desire to get PowerFAIDS NetPartner SSO working with Shibboleth’s SAML implementation.  In November of 2014, mrahman posted instructions for doing this with Shib 2.4.2, and I recall having this work for me (see http://shibboleth.net/pipermail/users/2014-November/018121.html).  However, I have not had success in implementing NetParter SSO with Shibboleth 3.  Based on my logs (in debug mode), my hangup at present seems to be that “no relying party configurations ae applicable”, even though I have the relying party configured.  Following is my idp-process log:

---BEGIN LOG---
2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.CheckMessageVersionHandler' on INBOUND message context
2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'
2018-05-08 11:27:17,533 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.saml1.binding.impl.SAML1ArtifactRequestIssuerHandler' on INBOUND message context
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLProtocolAndRoleHandler' on INBOUND message context
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler' on INBOUND message context
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:154] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler of type 'org.opensaml.saml.common.binding.impl.SAMLAddAttributeConsumingServiceHandler' on INBOUND message context
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.profile.impl.WebFlowMessageHandlerAdaptor:175] - Profile Action WebFlowMessageHandlerAdaptor: Invoking message handler on message context containing a message of type 'org.opensaml.saml.saml2.core.impl.AuthnRequestImpl'
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.saml.profile.impl.InitializeRelyingPartyContextFromSAMLPeer:132] - Profile Action InitializeRelyingPartyContextFromSAMLPeer: Attaching RelyingPartyContext based on SAML peer NetPartner
2018-05-08 11:27:17,548 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:293] - Resolving relying party configuration
...(non relevant lines removed)…
2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:305] - Checking if relying party configuration EntityNames[https://mynetpartnerhost.myuniversity.edu,] is applicable
2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:310] - Relying party configuration EntityNames[https:// mynetpartnerhost. myuniversity.edu,] is not applicable
2018-05-08 11:27:17,564 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:314] - No relying party configurations are applicable, returning the default configuration shibboleth.DefaultRelyingParty
---END LOG---


I added the following bean to my relying-party.xml file to use the Spriden ID (from Banner) for NetPartner:

---BEGIN BEAN---
        <bean parent="RelyingPartyByName" c:relyingPartyIds="https://mynetpartnerhost.myuniversity.edu">
            <property name="profileConfigurations">
                <list>
                        <bean parent="SAML2.SSO"
                                p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
                                p:encryptNameIDs="false"
                                p:encryptAssertions="false"
                        />
                </list>
            </property>
        </bean>
---END BEAN---


The following is my metadata file for netpartner:

---BEGIN METADATA---
<EntityDescriptor entityID="NetPartner"
        xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
        <SPSSODescriptor
            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
        <AssertionConsumerService index="1"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
            Location="https://mynetpartnerhost.myuniversity.edu/NetPartnerStudent/Logon.aspx"/>
        </SPSSODescriptor>
</EntityDescriptor>
---END METADATA---


I can provide additional configurations and/or complete files if helpful.  Any ideas?

By the way, if I can get NetPartner working with Shibboleth IdP v3, I will be happy to post results.




Carl R. Daudt
Enterprise Applications Systems Analyst, Information Technology
Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313
[hidden email]<mailto:[hidden email]>



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Peter Schober
In reply to this post by Daudt, Carl
* Daudt, Carl <[hidden email]> [2018-05-08 22:06]:

>         <bean parent="RelyingPartyByName" c:relyingPartyIds="https://mynetpartnerhost.myuniversity.edu">
>             <property name="profileConfigurations">
>                 <list>
>                         <bean parent="SAML2.SSO"
>                                 p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
>                                 p:encryptNameIDs="false"
>                                 p:encryptAssertions="false"
>                         />
>                 </list>
>             </property>
>         </bean>

Also note that you already have the NameIDFormat in the metadata, and
that encryption of NameIDs has not been the default for many, many
years now. So the only relevant setting there is avoiding encryption
of the assertion.
In case you've set idp.encryption.optional to true in your
conf/idp.properties that would make the whole relaying party override
above superfluous. (Not that I'm advocating you set this now, just
that if you had it, you wouldn't need any of the above.)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

OK, I now have the following for my relying-part.xml configuration, which is getting me a lot further:

---BEGIN---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="NetPartner">

            <property name="profileConfigurations">

                <list>

                                                <bean parent="SAML2.SSO"

                                                                p:encryptAssertions="false"

                                                />

                </list>

            </property>

        </bean>

---END---

 

My metadata is unchanged.

 

I am properly redirected to my CAS login screen (our Shibboleth configuration uses CAS for logins), and then I am redirected back to NetPartner, albeit with an “Invalid Single Sign On Response” message, which I will explain below.

 

My shibboleth logs end with the following entry:

---BEGIN---

2018-05-11 10:38:59,599 - INFO [Shibboleth-Audit.SSO:241] - 20180511T143859Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|dcdgnhncfmpgmahebjiejlpbekfpgjmadbofekpb|NetPartner|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://myshibbolethserver.myuniversity.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_2062f2d7c57e755b95757862a95dceab|crdaudt|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|netPartnerStudentID|AAdzZWNyZXQxYmLfPXBwREDYO4i78NsYwsnyDjrHRmXo+MXbxn5A2zzz4beCrAbfyrwNsPEbV04NSTKmJ6yIoVBFAizssJI3Dm6QhfxajQGO2ERY+iZ5d9Y=|_dc25b38190cd8aa953c635901fe5ab80|

---END---

 

My Net Partner logs indicate an ERROR that “SSO Response Digital Signature could not be validated”.

 

In my Net Partner configuration, I have specified that the Public Key Certificate” for my IdP is my idp-encryption.crt file (I have also tried idp-signing.crt – to be honest, I am not sure which to use).  I have also specified that my IdP URL is https://myshibbolethserver.myuniversity.edu/idp/profile/SAML2/Redirect/SSO , my Protocol Binding is POST, and my Requested NameId Format is unspecified (other options include persistent, transient, emailAdress, and various other options).

 

Any further suggestions?

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Peter Schober
* Daudt, Carl <[hidden email]> [2018-05-11 17:30]:
> My Net Partner logs indicate an ERROR that "SSO Response Digital
> Signature could not be validated".

Simple: You gave the IDP the wrong cert.

> In my Net Partner configuration, I have specified that the Public
> Key Certificate" for my IdP is my idp-encryption.crt file (I have
> also tried idp-signing.crt - to be honest, I am not sure which to
> use).

In order to validate your signature the SP needs your signing cert,
not encryption. (And you only have to even deal with these sorts of
questions because the SP doesn't support standard SAML 2.0 Metadata).

> I have also specified that my IdP URL is
> https://myshibbolethserver.myuniversity.edu/idp/profile/SAML2/Redirect/SSO
> my Protocol Binding is POST, and my Requested NameId Format is
> unspecified (other options include persistent, transient,
> emailAdress, and various other options).

Hard to say, not knowing the SP. And there are 2 "protocol bindings"
involved: How the authenticaton request from the SP is sent to the
IDP, and how to send the response from the IDP back to the SP.

Given your SSO URL above this means the SP would have to send the
request using HTTP-Redirect binding. If they do, that will be fine.

If they send the request using HTTP-POST (which you'll know from the
error message the IDP will generate in that case) you'd have to give
them the URL of your HTTP-POST SSO endpoint instead (s/Redirect/POST/
in the URL above).  For the response your IDP will use the HTTP-POST
binding, so if "Protocol Binding is POST" refers to the response then
that's fine. (If it means the request then change the SSO URL as per
above.)

You don't provide sufficient details to give specific advise about
NameID configuration. I'd avoid using unspecified if at all possible.
According to the post from the archives you reference the expected
data is some form of "employeeID"? None of the NameID formats OASIS
defined are suitable for that.
Maybe the don't even check the format, though, many "vended" SPs don't
even bother. In that case you can send any NameID format URI you like,
including e.g. urn:oid:... for the LDAP attribute you're sending them.

That at least avoids having to dig into activation conditions when the
next SP comes along that specifically expects you to send something
very differently but also in an "unspecified" NameID.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Tony Skalski
In reply to this post by Daudt, Carl
Hi Carl,

We've had NetPartner working for some time. My configuration notes says that NetPartner requires the NameID to be an email address but in unspecified format, because this is the match field to records in the back-end database. (I don't recall if this is a specific requirement or just that we specify email address as the match field in NP Manager (I don't have access to NP Manager config at the moment)). So this may or may not effect your use of the "Spriden ID" as the NameID.

In NP Manager we set the protocol binding to POST but the IdP URL to https://login.stolaf.edu/idp/profile/SAML2/Redirect/SSO which seems to jibe with your config.

I do notice one difference in our configs: in our relying part override, we have set "p:securityConfiguration-ref="SHA1SecurityConfig". IIRC, when we upgraded to v3, NetPartner did not work until we added that line. Here are our relevant config bits:

metadata:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="NetPartner">
        <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
                <md:AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://blah.stolaf.edu/NetPartner/NetPartnerStudent/Logon.aspx" />
        </md:SPSSODescriptor>
</md:EntityDescriptor>

relying-party.xml:
        <!-- Some SPs need nameid to be email address in format:unspecified. -->
        <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{
            'NetPartner',
            '***.***.***',
            '****.***.***'
            }}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO"
                        p:encryptAssertions="false"
                        p:encryptNameIDs="false"
                        p:securityConfiguration-ref="SHA1SecurityConfig"
                        p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified'}}" />
                    <ref bean="SAML2.Logout" />
               </list>
            </property>
        </bean>




On Fri, May 11, 2018 at 10:29 AM Daudt, Carl <[hidden email]> wrote:

OK, I now have the following for my relying-part.xml configuration, which is getting me a lot further:

---BEGIN---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="NetPartner">

            <property name="profileConfigurations">

                <list>

                                                <bean parent="SAML2.SSO"

                                                                p:encryptAssertions="false"

                                                />

                </list>

            </property>

        </bean>

---END---

 

My metadata is unchanged.

 

I am properly redirected to my CAS login screen (our Shibboleth configuration uses CAS for logins), and then I am redirected back to NetPartner, albeit with an “Invalid Single Sign On Response” message, which I will explain below.

 

My shibboleth logs end with the following entry:

---BEGIN---

2018-05-11 10:38:59,599 - INFO [Shibboleth-Audit.SSO:241] - 20180511T143859Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|dcdgnhncfmpgmahebjiejlpbekfpgjmadbofekpb|NetPartner|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://myshibbolethserver.myuniversity.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_2062f2d7c57e755b95757862a95dceab|crdaudt|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|netPartnerStudentID|AAdzZWNyZXQxYmLfPXBwREDYO4i78NsYwsnyDjrHRmXo+MXbxn5A2zzz4beCrAbfyrwNsPEbV04NSTKmJ6yIoVBFAizssJI3Dm6QhfxajQGO2ERY+iZ5d9Y=|_dc25b38190cd8aa953c635901fe5ab80|

---END---

 

My Net Partner logs indicate an ERROR that “SSO Response Digital Signature could not be validated”.

 

In my Net Partner configuration, I have specified that the Public Key Certificate” for my IdP is my idp-encryption.crt file (I have also tried idp-signing.crt – to be honest, I am not sure which to use).  I have also specified that my IdP URL is https://myshibbolethserver.myuniversity.edu/idp/profile/SAML2/Redirect/SSO , my Protocol Binding is POST, and my Requested NameId Format is unspecified (other options include persistent, transient, emailAdress, and various other options).

 

Any further suggestions?

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
Tony Skalski
System Administrator | IT

Office: <a href="javascript:void(0);" target="_blank">507-786-3227
1510 St. Olaf Avenue Northfield, MN 55057


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

Tony, when you set "p:securityConfiguration-ref="SHA1SecurityConfig" in your relying-party.xml, did you have to define SHA1SecurityConfig somewhere?

I am receiving the following warning and error in my shib logs when I attempt to add the line:

 

---BEGIN---

2018-05-11 14:57:34,632 - WARN [net.shibboleth.ext.spring.context.FilesystemGenericApplicationContext:545] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.RelyingPartyOverrides': Cannot create inner bean 'RelyingPartyByName$child#41e65c1e' of type [net.shibboleth.idp.saml.relyingparty.impl.RelyingPartyConfigurationSupport] while setting bean property 'sourceList' with key [8]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'RelyingPartyByName$child#41e65c1e' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot create inner bean 'SAML2.SSO$child#2252c99d' of type [net.shibboleth.idp.saml.saml2.profile.config.BrowserSSOProfileConfiguration] while setting bean property 'profileConfigurations' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'SAML2.SSO$child#2252c99d' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot resolve reference to bean 'SHA1SecurityConfig' while setting bean property 'securityConfiguration'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

2018-05-11 14:57:34,695 - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:181] - Service 'shibboleth.RelyingPartyResolverService': Initial load failed

net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.RelyingPartyOverrides': Cannot create inner bean 'RelyingPartyByName$child#41e65c1e' of type [net.shibboleth.idp.saml.relyingparty.impl.RelyingPartyConfigurationSupport] while setting bean property 'sourceList' with key [8]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'RelyingPartyByName$child#41e65c1e' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot create inner bean 'SAML2.SSO$child#2252c99d' of type [net.shibboleth.idp.saml.saml2.profile.config.BrowserSSOProfileConfiguration] while setting bean property 'profileConfigurations' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'SAML2.SSO$child#2252c99d' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot resolve reference to bean 'SHA1SecurityConfig' while setting bean property 'securityConfiguration'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

        at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:334)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.RelyingPartyOverrides': Cannot create inner bean 'RelyingPartyByName$child#41e65c1e' of type [net.shibboleth.idp.saml.relyingparty.impl.RelyingPartyConfigurationSupport] while setting bean property 'sourceList' with key [8]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'RelyingPartyByName$child#41e65c1e' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot create inner bean 'SAML2.SSO$child#2252c99d' of type [net.shibboleth.idp.saml.saml2.profile.config.BrowserSSOProfileConfiguration] while setting bean property 'profileConfigurations' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'SAML2.SSO$child#2252c99d' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot resolve reference to bean 'SHA1SecurityConfig' while setting bean property 'securityConfiguration'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'RelyingPartyByName$child#41e65c1e' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot create inner bean 'SAML2.SSO$child#2252c99d' of type [net.shibboleth.idp.saml.saml2.profile.config.BrowserSSOProfileConfiguration] while setting bean property 'profileConfigurations' with key [0]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'SAML2.SSO$child#2252c99d' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot resolve reference to bean 'SHA1SecurityConfig' while setting bean property 'securityConfiguration'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'SAML2.SSO$child#2252c99d' defined in file [E:\shibboleth3\idp\conf\relying-party.xml]: Cannot resolve reference to bean 'SHA1SecurityConfig' while setting bean property 'securityConfiguration'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

        at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:359)

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'SHA1SecurityConfig' is defined

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:698)

 

---END---

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Cantor, Scott E.
> Tony, when you set "p:securityConfiguration-ref="SHA1SecurityConfig" in your
> relying-party.xml, did you have to define SHA1SecurityConfig somewhere?

https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration

Per-Profile Signing Algorithm

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Tony Skalski
Sorry - forgot to copy two lines above the relying-party.xml snippet:

    <bean id="SHA1SecurityConfig" parent="shibboleth.DefaultSecurityConfiguration"
        p:signatureSigningConfiguration-ref="shibboleth.SigningConfiguration.SHA1" />

ajs

On Fri, May 11, 2018 at 2:19 PM Cantor, Scott <[hidden email]> wrote:
> Tony, when you set "p:securityConfiguration-ref="SHA1SecurityConfig" in your
> relying-party.xml, did you have to define SHA1SecurityConfig somewhere?

https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration

Per-Profile Signing Algorithm

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
Tony Skalski
System Administrator | IT

Office: <a href="javascript:void(0);" target="_blank">507-786-3227
1510 St. Olaf Avenue Northfield, MN 55057


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

Thanks Tony.  This has brought me beyond the certificate issue that presented me with the NetPartner “Invalid Single Sign On Response” message.  In fact, I think I am close, but either NetPartner is not processing the netPartnerStudentID (an ID from our Banner database), or the netPartnerStudentID is not populated with the data I expect.  Based on my Shibboleth debug logs, I believe NetPartner is trying to use the wrong attribute, because netPartnerStudentID appears to be populated correctly.

 

I wonder if I need to configure Shibboleth to use netPartnerStudentID as my transient ID?  Tony, perhaps you can help here.

 

 

Here are relevant error messages, log entries, and Shibboleth configurations:

 

The error message presented to the user by NetPartner is “Your login failed.  We could not validate your netPartnerStudentID”.

 

There is no entry recorded in the NetPartner NPStudent.log file (when I had certificate issues, there was an error entry in this file).

 

--From my Shibboleth idp-process.log, I have the following:

------ BEGIN id-process.log -------

2018-05-14 10:55:18,808 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] - Attribute Definition 'netPartnerStudentID': produced an attribute with the following values [StringAttributeValue{value=@12345678}]

  (where “@12345678” matches the BannerID for the NetPartner User, as identified in the NetPartner “Alternet ID” field that is used for NetPartner logins).

--- and ---

2018-05-14 10:55:19,011 - INFO [Shibboleth-Audit.SSO:241] - 20180514T145519Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|llcpcpikeeagmlemdfpnapkbjmimiabncmcipeno|NetPartner|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://myshibbolethserver.myuniversity.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_e1728…677f2b|crdaudt|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|netPartnerStudentID|AAdzZW…H6Hqg=|_13f33…dc545|

------ END id-process.log -------

Note about the logs above:  I do not know if the fact that both my username, “crdaudt”, and a hash for the netPartnerStudentID is being retured to the service provider is relevant.

 

Here is my configuration in saml-named.xml:

------ BEGIN ------

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>https://mynetpartnerserver.myuniversity.edu</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

------ END ------

 

Any thoughts?

 

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Peter Schober
* Daudt, Carl <[hidden email]> [2018-05-14 17:33]:
> 2018-05-14 10:55:19,011 - INFO [Shibboleth-Audit.SSO:241] -
> 20180514T145519Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|llcpcpikeeagmlemdfpnapkbjmimiabncmcipeno|NetPartner|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://myshibbolethserver.myuniversity.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_e1728...677f2b|crdaudt|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|netPartnerStudentID|AAdzZW...H6Hqg=|_13f33...dc545|
>
> Note about the logs above: I do not know if the fact that both my
> username, "crdaudt", and a hash for the netPartnerStudentID is being
> retured to the service provider is relevant.

That's not what the above means, so that's not what happened.
(Check the documentation for the default audit log file format.)

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Tony Skalski
In reply to this post by Daudt, Carl
In your activationCondition, I think you want the value to be the NetPartner EntityId, which is simply "NetPartner".

ajs

On Mon, May 14, 2018 at 10:32 AM Daudt, Carl <[hidden email]> wrote:

Thanks Tony.  This has brought me beyond the certificate issue that presented me with the NetPartner “Invalid Single Sign On Response” message.  In fact, I think I am close, but either NetPartner is not processing the netPartnerStudentID (an ID from our Banner database), or the netPartnerStudentID is not populated with the data I expect.  Based on my Shibboleth debug logs, I believe NetPartner is trying to use the wrong attribute, because netPartnerStudentID appears to be populated correctly.

 

I wonder if I need to configure Shibboleth to use netPartnerStudentID as my transient ID?  Tony, perhaps you can help here.

 

 

Here are relevant error messages, log entries, and Shibboleth configurations:

 

The error message presented to the user by NetPartner is “Your login failed.  We could not validate your netPartnerStudentID”.

 

There is no entry recorded in the NetPartner NPStudent.log file (when I had certificate issues, there was an error entry in this file).

 

--From my Shibboleth idp-process.log, I have the following:

------ BEGIN id-process.log -------

2018-05-14 10:55:18,808 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:247] - Attribute Definition 'netPartnerStudentID': produced an attribute with the following values [StringAttributeValue{value=@12345678}]

  (where “@12345678” matches the BannerID for the NetPartner User, as identified in the NetPartner “Alternet ID” field that is used for NetPartner logins).

--- and ---

2018-05-14 10:55:19,011 - INFO [Shibboleth-Audit.SSO:241] - 20180514T145519Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|llcpcpikeeagmlemdfpnapkbjmimiabncmcipeno|NetPartner|http://shibboleth.net/ns/profiles/saml2/sso/browser|https://myshibbolethserver.myuniversity.edu/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_e1728…677f2b|crdaudt|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|netPartnerStudentID|AAdzZW…H6Hqg=|_13f33…dc545|

------ END id-process.log -------

Note about the logs above:  I do not know if the fact that both my username, “crdaudt”, and a hash for the netPartnerStudentID is being retured to the service provider is relevant.

 

Here is my configuration in saml-named.xml:

------ BEGIN ------

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>https://mynetpartnerserver.myuniversity.edu</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

------ END ------

 

Any thoughts?

 

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
Tony Skalski
System Administrator | IT

Office: <a href="javascript:void(0);" target="_blank">507-786-3227
1510 St. Olaf Avenue Northfield, MN 55057


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

Are you saying to change “https://myfapprd.taylor.edu” to “NetPartner” in saml-nameid.xml?  Currently I have:

 

------ saml-nameid.xml ------

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>https://myfapprd.taylor.edu</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

 

> In your activationCondition, I think you want the value to be the

> NetPartner EntityId, which is simply "NetPartner".

>

> ajs

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Tony Skalski
Yes. Your metadata specifies the entity id 'NetPartner' (and that is what is hard-coded into the SP itself). When the activation condition matches the NetPartner entity id, it will generate a NameID with format unspecified from your netPartnerStudentID attribute.

ajs



On Mon, May 14, 2018 at 12:17 PM Daudt, Carl <[hidden email]> wrote:

Are you saying to change “https://myfapprd.taylor.edu” to “NetPartner” in saml-nameid.xml?  Currently I have:

 

------ saml-nameid.xml ------

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>https://myfapprd.taylor.edu</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

 

> In your activationCondition, I think you want the value to be the

> NetPartner EntityId, which is simply "NetPartner".

>

> ajs

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
Tony Skalski
System Administrator | IT

Office: <a href="javascript:void(0);" target="_blank">507-786-3227
1510 St. Olaf Avenue Northfield, MN 55057


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

Uggh, I think I am close, but am still getting the same error from NetPartner:  “Your login failed. We could not validate your User Name.”

Any new ideas?

 

Here is a recap:  Here is what I have for Shib:

 

Your assistance is greatly appreciated!!

 

--- metadata ---

<EntityDescriptor entityID="NetPartner"

                xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

        <SPSSODescriptor

            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol

            urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">

        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

        <AssertionConsumerService index="1"

            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Location="https://myfapprd.taylor.edu/NetPartnerStudent/Logon.aspx"/>

        </SPSSODescriptor>

</EntityDescriptor>

 

--- attribute-resolver.xml ---

    <resolver:AttributeDefinition xsi:type="Simple" id="netPartnerStudentID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="SpriIdAlias">

        <resolver:Dependency ref="mySIS2" />

        <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

    </resolver:AttributeDefinition>

 

    <resolver:AttributeDefinition xsi:type="ad:TransientId" id="transientId">

        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />

        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />

    </resolver:AttributeDefinition>

 

--- attribute-filter.xml ---

    <AttributeFilterPolicy id="releaseForNetPartnerSP">

        <PolicyRequirementRule xsi:type="Requester" value="NetPartner" />

        <AttributeRule attributeID="netPartnerStudentID">

            <PermitValueRule xsi:type="ANY"/>

        </AttributeRule>

    </AttributeFilterPolicy>

 

--- relying-party.xml ---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="NetPartner">

            <property name="profileConfigurations">

                <list>

                    <bean parent="Shibboleth.SSO" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ECP" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.Logout" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                                    <bean parent="SAML2.SSO"

                                                p:encryptAssertions="false"

                                                p:securityConfiguration-ref="SHA1SecurityConfig"

                                     />

                </list>

            </property>

        </bean>

 

--- saml-nameid.xml ---

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>NetPartner</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

 

The Shibboleth idp-process.log file shows (with debug turned on) that the attribute netPartnerStudentID has a value of @12345678 (numerical value reported here is modified for security), and is released to NetPartner.

In NetPartner, the same value is set for both the Alternate ID and Web ID for a test student to @12345678.  When NetPartner is configured for regular login, I can log in for that user.  But when I set NetPartner for SAML Single Sign on, I get the error above.

 

 

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Tony Skalski
In NetPartner Manager, on the Login tab, is the "Students login using" set to either the Alternate ID or Web ID? We use email1 because we are sending an email as a NameID (using format unspecified - of course!).

Don't suppose there are any clues in the NPStudent.log...



On Mon, May 14, 2018 at 4:07 PM Daudt, Carl <[hidden email]> wrote:

Uggh, I think I am close, but am still getting the same error from NetPartner:  “Your login failed. We could not validate your User Name.”

Any new ideas?

 

Here is a recap:  Here is what I have for Shib:

 

Your assistance is greatly appreciated!!

 

--- metadata ---

<EntityDescriptor entityID="NetPartner"

                xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

        <SPSSODescriptor

            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol

            urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">

        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

        <AssertionConsumerService index="1"

            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Location="https://myfapprd.taylor.edu/NetPartnerStudent/Logon.aspx"/>

        </SPSSODescriptor>

</EntityDescriptor>

 

--- attribute-resolver.xml ---

    <resolver:AttributeDefinition xsi:type="Simple" id="netPartnerStudentID" xmlns="urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="SpriIdAlias">

        <resolver:Dependency ref="mySIS2" />

        <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

    </resolver:AttributeDefinition>

 

    <resolver:AttributeDefinition xsi:type="ad:TransientId" id="transientId">

        <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />

        <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />

    </resolver:AttributeDefinition>

 

--- attribute-filter.xml ---

    <AttributeFilterPolicy id="releaseForNetPartnerSP">

        <PolicyRequirementRule xsi:type="Requester" value="NetPartner" />

        <AttributeRule attributeID="netPartnerStudentID">

            <PermitValueRule xsi:type="ANY"/>

        </AttributeRule>

    </AttributeFilterPolicy>

 

--- relying-party.xml ---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="NetPartner">

            <property name="profileConfigurations">

                <list>

                    <bean parent="Shibboleth.SSO" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ECP" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.Logout" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                                    <bean parent="SAML2.SSO"

                                                p:encryptAssertions="false"

                                                p:securityConfiguration-ref="SHA1SecurityConfig"

                                     />

                </list>

            </property>

        </bean>

 

--- saml-nameid.xml ---

                <bean parent="shibboleth.SAML2AttributeSourcedGenerator"

                                p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

                                p:attributeSourceIds="#{ {'netPartnerStudentID'} }"

                >

                                <property name="activationCondition">

                                                <bean parent="shibboleth.Conditions.RelyingPartyId">

                                                                <constructor-arg name="candidates">

                                                                                <list>

                                                                                                <value>NetPartner</value>

                                                                                </list>

                                                                </constructor-arg>

                                                </bean>

                                </property>

                </bean>

 

The Shibboleth idp-process.log file shows (with debug turned on) that the attribute netPartnerStudentID has a value of @12345678 (numerical value reported here is modified for security), and is released to NetPartner.

In NetPartner, the same value is set for both the Alternate ID and Web ID for a test student to @12345678.  When NetPartner is configured for regular login, I can log in for that user.  But when I set NetPartner for SAML Single Sign on, I get the error above.

 

 

 

Carl R. Daudt

Enterprise Applications Systems Analyst, Information Technology

Taylor University
236 W. Reade Avenue
Upland, IN  46989
Office:  765-998-5313

[hidden email]

 



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
Tony Skalski
System Administrator | IT

Office: 507-786-3227
1510 St. Olaf Avenue Northfield, MN 55057


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Daudt, Carl
In reply to this post by Daudt, Carl

Well, I finally got Shibboleth SSO working for Net Partner.  Thank you all for assisting, especially Tony.  I will perform some clean up of my configs and provide a summary.

 

The most recent issue was fixed by changing where I specified the NameIDFormat, which I had in the Net Partner metadata file.  I had the following:

 

--- metadata ---

<EntityDescriptor entityID="NetPartner"

                xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

        <SPSSODescriptor

            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol

            urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">

        <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

        <AssertionConsumerService index="1"

            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Location="https://myfapprd.taylor.edu/NetPartnerStudent/Logon.aspx"/>

        </SPSSODescriptor>

</EntityDescriptor>

 

The change that got Net Partner SSO working for was removing the sixth line (i.e., the <NameIDFormat> specification from the metadata file.  Instead, I placed the specification as a nameIDFormatPrecedence entry in reying-party.xml as follows:

 

--- NetPartner entry for relying-party.xml ---

        <bean parent="RelyingPartyByName" c:relyingPartyIds="NetPartner">

            <property name="profileConfigurations">

                <list>

                    <bean parent="Shibboleth.SSO" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML1.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ECP" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.Logout" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.AttributeQuery" p:securityConfiguration-ref="SHA1SecurityConfig" />

                    <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="SHA1SecurityConfig" />

                                    <bean parent="SAML2.SSO"

                                                p:encryptAssertions="false"

                                                p:securityConfiguration-ref="SHA1SecurityConfig"

                                                p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'}}"

                                     />

                </list>

            </property>

        </bean>

 

I admit to being confused why this change worked—it seems like it should have worked in my metadata file.

 

In response to Peter’s suggestion that I “…avoid using the ‘unspecified’ (nameid-format) if at all possible”, I tried another value, only to have things break for me.  It seems that the ‘unspecified’ settings is what works here.

 

Again, I will post a summary of all of my Shibboleth and Net Partner configs for supporting PowerFAIDS Net Partner SSO.  This might take me a couple days or so.

 

Carl



The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Peter Schober
* Daudt, Carl <[hidden email]> [2018-05-15 20:17]:
> The most recent issue was fixed by changing where I specified the
> NameIDFormat, which I had in the Net Partner metadata file.
[...]
> The change that got Net Partner SSO working for was removing the
> sixth line (i.e., the <NameIDFormat> specification from the metadata
> file.  Instead, I placed the specification as a
> nameIDFormatPrecedence entry in reying-party.xml

That would be a bug effecting noone else so far.

FWIW, I only use SAML Metadata for NameID selection and it works fine
for me.
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Lipscomb, Gary
In reply to this post by Daudt, Carl
Doesn't V3 ignore
      <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
if it's in  metadata anyway?

   idp-warn-2018-05-15.log.gz:2018-05-15 12:31:07,038 - WARN [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:75] - Ignoring NameIDFormat metadata that includes the 'unspecified' format  

Regards

Gary

-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Peter Schober
Sent: Wednesday, 16 May 2018 16:34
To: [hidden email]
Subject: Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

* Daudt, Carl <[hidden email]> [2018-05-15 20:17]:
> The most recent issue was fixed by changing where I specified the
> NameIDFormat, which I had in the Net Partner metadata file.
[...]
> The change that got Net Partner SSO working for was removing the
> sixth line (i.e., the <NameIDFormat> specification from the metadata
> file.  Instead, I placed the specification as a
> nameIDFormatPrecedence entry in reying-party.xml

That would be a bug effecting noone else so far.

FWIW, I only use SAML Metadata for NameID selection and it works fine
for me.
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Re: Getting PowerFAIDS NetPartner to work with Shibboleth 3

Peter Schober
* Lipscomb, Gary <[hidden email]> [2018-05-16 08:47]:
> Doesn't V3 ignore
>       <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
> if it's in  metadata anyway?

Ah, my bad. I don't use that format anywhere.
So for this and only this format using metadata does not work.

Would adding a property (idp.nameid.allowUnspecified?) to allow use of
metadata with this format make sense? Or are there too many other
overrides and activation conditions and whatnot necessary anyway to
make "unspecifified" work with some specific content that this doesn't
make things any easier?
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
12