Getting PowerFAIDS NetPartner to work with Shibboleth 3

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

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

Cantor, Scott E.
> 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?

Formally by standard, we don't believe it's possible for anybody to "request" a Format that literally means "I don't care what the Format is".

-- 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

Daudt, Carl
In reply to this post by Daudt, Carl
As promised, here is a summary of steps required to support Single Sign On (SSO) with SAML for the PowerFAIDS Net Partner web app using the Shibboleth 3.0 identity provider.  PowerFAIDS is a product of The College Board, Inc.  I am not a Shibboleth or SAML expert and certainly cannot claim that the following steps follow best practices.  But the end result seems to be working for us, so I hope they prove to be helpful to someone.  Feel free to reply with improvements where appropriate.  I will not be offended if someone corrects any false or ignorant statements I make.

As pointed out at the beginning of this thread, instructions were posted for doing this with Shibboleth 2.4.2 in November of 2014 by mrahman (see http://shibboleth.net/pipermail/users/2014-November/018121.html).  Enough changes have occurred with version 3.0 that I am providing these updated steps.

Net Partner documentation and log file for SSO can be found in the following locations:
--"Net Partner User Guide":  Find the Chapter of "Building your Institution's Student Portal" which contains a section entitled "Creating the Log In Page".  Within the section is a subsection entitled "Enabling Single Sign On (SSO)".
--"Net Partner Installation and Maintenance Guide":  Refer to Chapter 8:  "About Single Sign-On" (which is very short--only three paragraphs).  Also refer to Appendix A: "About SAML" which provides a more detailed overview of the SAML implementation in Net Partner.
--Also in the "Net Partner Installation and Maintenance Guide":  Refer to Chapter 10: "Troubleshooting" for hints on troubleshooting SSO issues.
--There is a log file for Net Partner that might contain some useful debugging information for SSO related issues (Not enough!  I am not sure if there is any means of making the log more verbose).  The default location of the log file is c:\ProgramData\The College Board\PowerFaids\NPStudent.log

Background:  While Net Partner supports SAML SSO, it does not support standard SAML 2.0 metadata (at least at this time).  Instead, the assertion is signed with the IDP's signing certificate (a SHA1 certificate at that!).  All this requires a some "stooping down" (if you will!) to some limitations imposed by the Net Partner Service Provider.

Net Partner supports using the PowerFAIDS "Web ID", "Alternate ID", "SSN", "E-mail 1", or E-mail 2" fields for uniquely identifying each user at login, regardless of whether one is using SSO or straight login (Please stay away from the "SSN" option!).    At my institution, we populate the PowerFAIDS field "Alternate ID" with a unique student ID number that is stored in a separate database.  You might prefer to use one of the other fields above, or to populate either the Alternate ID or Web ID with the sAMAccountName (username) from your LDAP system.


Steps:

____ Metadata (stored in a file that we named metadata/netpartner.xml): ____

---BEGIN FILE---
<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">
        <AssertionConsumerService index="1"
            Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Location="https://mynetpartnerserver.myinstitution.edu/NetPartnerStudent/Logon.aspx"/>
        </SPSSODescriptor>
</EntityDescriptor>
---END FILE---

Notes:  Observe that the metadata file is devoid of any actual SAML 2 metadata (which Net Partner SSO does not support).  Please note that the value of the entityID needs to be consistent between the file above, the relyingPartyIDs where specified in both relying-party.xml and saml-nameid.xml, and the Service Provider Name as specified in Net Partner.  At one time, I believe the value was hard coded as "NetPartner" in the web app.  In any case, I chose to stick with the value "NetPartner".


____ Addition to to metadata-providers.xml: ____
Insert the following lines prior to the final </MetadataProvider> line:

---BEGIN LINES FOR metadata-providers.xml---
    <MetadataProvider id="NetPartnerMD" xsi:type="FilesystemMetadataProvider"
        xmlns="urn:mace:shibboleth:2.0:metadata"
metadataFile="E:\shibboleth3\idp\metadata\netpartner.xml"/>
---END LINES FOR metadata-providers.xml---


____ Data Connector in attribute-resolver.xml for the attribute that will be released to Net Partner as the Student ID: ____

The following is how we define a connector for the Student ID field in PowerFAIDS (and Net Partner).  You might use something very different here.  At our institution, we use Ellucian Banner for our ERP, and the Banner "SPRIDEN_ID" is what we have populated the PowerFAIDS "Alternate ID" field with to uniquely identify each student.  The SPRIDEN_ID is not stored in our active directory (LDAP) server, so we need to pull it from our Banner database using the following relational database connector in attribute-resolver.xml:

---BEGIN LINES FOR SPRIDEN_ID CONNECTOR IN attribute-resolver.xml---
    <resolver:DataConnector xsi:type="dc:RelationalDatabase" id="mySIS2">
        <dc:ContainerManagedConnection resourceName="java:comp/env/jdbc/ORAIDP" />
        <dc:QueryTemplate>
            <![CDATA[
                SELECT SPRIDEN_ID FROM GOBUMAP INNER JOIN SPRIDEN ON SPRIDEN_PIDM = GOBUMAP_PIDM AND SPRIDEN_CHANGE_IND IS
                    NULL WHERE GOBUMAP_UDC_ID = LOWER('$requestContext.principalName')
            ]]>
        </dc:QueryTemplate>
        <dc:Column columnName="SPRIDEN_ID" attributeID="SpriIdAlias" />
    </resolver:DataConnector>
---END LINES FOR SPRIDEN_ID CONNECTOR IN attribute-resolver.xml---

To accomplish the above, we had to install an Oracle JDBC Thin Driver for in Tomcat.  Essentially this involves downloading a.jar file from Oracle and placing it in the $TOMCAT_HOME\lib directory.  We then needed to add an Oracle DB data connector to $TOMCAT_HOME\conf\Catalina\localhost\idp.xml (create the file if it does not already exist).  This is what our file looks like (search Shibboleth documentation for OracleDBDataConnector for more information):

---BEGIN FILE $TOMCAT_HOME\conf\Catalina\localhost\idp.xml---
<Context docBase="E:/shibboleth3/idp/war/idp.war"
privileged="true"
antiResourceLocking="false"
unpackWAR="false"
swallowOutput="true"
cookies="false" >

        <!-- Add following element to communicate with Banner database -->
<Resource name="jdbc/ORAIDP"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@mybannerserver.myinternalserverdomain.edu:1521:myoracleinstance"
validationQuiery="SELECT 1 from dual"
username="myoracleusernamet" password="mysecretpassword"
maxActive="20" maxIdle="10" maxWait="-1" />
</Context>
---END FILE $TOMCAT_HOME\conf\Catalina\localhost\idp.xml---


____ Attribute Definitions in attribute-resolver.xml for the attribute that will be released to Net Partner as the Student ID: ____

Once the data connector for the Net Partner student identifier has been configured (whether from Banner as I did above, LDAP, or some other source), the attribute can be resolved.  In the example below, I resolve what I have identified as the "netPartnerStudentID" attribute (for which the source is "SpriIdAlias" in my data connector above).  Your "<resolver:Dependency ref=...>" value will be different if you are referencing an LDAP or other connector.

I am also resolving a Transient ID here.  My Net Partner-related attribution definitions are as follows:

---BEGIN LINES FOR ATTRIBUTE DEFINITIONS IN 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>
---END LINES FOR ATTRIBUTE DEFINITIONS IN attribute-resolver.xml---

Notes:  I have specified here that in the case of netPartnerStudentID, the nameFormat for both the SAML1StringNameIdentifier and SAML2StringNameID is set to="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified".  I understand that it is better if your field can be release in some nameFormat that is something more definitive than 'unspecified'.  I am not sure if this will work in my case.  More about this follows in my steps for relying-party.xml and saml-nameid.xml (below).


____ Override to add to relying-party.xml: ____

Following the default configuration (i.e., the bean with the id="shibboleth.DefaultRelyingParty"), add the following bean to support SHA1 signatures (NetPartner's implementation of SAML only allows a SHA1 signed attribute for the student id).  This is further documented in https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration.  Here is the bean to be added:

---BEGIN LINES FOR SHA1SecurityConfig---
    <bean id="SHA1SecurityConfig" parent="shibboleth.DefaultSecurityConfiguration"
        p:signatureSigningConfiguration-ref="shibboleth.SigningConfiguration.SHA1" /
---END LINES FOR SHA1SecurityConfig---

Then in the container for additional overrides, (i.e., within the container <util:list id="shibboleth.RelyingPartyOverrides"> ), add the following:

---BEGIN relying-party OVERRIDE FOR NetPartner---
        <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>
---END relying-party OVERRIDE FOR NetPartner---

Again, I understand that it is better if your field can be release in some nameFormat that is something more definitive than 'unspecified'.  Incidentally, rather than specifying the "p:nameIDFormatPrecedence=..." line here in the relying-party overrides section, I had attempted to do so in the metadata section with a the following specification for NameIDFormat:

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

Version 2.x of Shibboleth allowed this, but Version 3 does not.  It generates the following warning in idp-process.log:
WARN [org.opensaml.saml.common.profile.logic.MetadataNameIdentifierFormatStrategy:75] - Ignoring NameIDFormat metadata that includes the 'unspecified' format

As Scott alluded to in his comment earlier in this thread, why should anybody "...'request' a Format that literally means 'I don't care what the Format is'"?  In conclusion, since I could only specify that the assertion is to be in an unspecified format that is not specified, I accomplished this by doing so as an override in relying-party.xml.


____ SAML NameID Generation to be added to saml-nameid.xml ____

We need to use the Net Partner Student Login ID as our SAML NameID.  This is done by adding the following bean in the container <util:list id="shibboleth.SAML2NameIDGenerators"> as follows:

---BEGIN BEAN FOR USING netPartnerStudentID as our SAML NameID---
<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>
---END BEAN FOR USING netPartnerStudentID as our SAML NameID---


____ Allow attributes to be released to Net Partner in  attribute-filter.xml ____

The following Attribute filter policy needs to be added to attribute-filter.xml within the <AttributeFilterPolicyGroup id="ShibbolethFilterPolicy" container:

---BEGIN AttributeFilterPolicy LINES FOR attribute-filter.xml---
    <AttributeFilterPolicy id="releaseForNetPartnerSP">
        <PolicyRequirementRule xsi:type="Requester" value="NetPartner" />
        <AttributeRule attributeID="netPartnerStudentID">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
    </AttributeFilterPolicy>
---END AttributeFilterPolicy LINES FOR attribute-filter.xml---


____ Net Partner Configurations ____

Finally, we need to configure Net Partner to use SSO.  Log into the Net Partner Manager Web App with the admin account and perform the following steps:
--Select the "LOG IN" tab
--Set "Students Log In Using" to "Alternate ID" (at least in my case).
--Set "Use Single Sign-On" to 'Yes'.  This will cause several more settings to become visible.
--Set the "Identity Provider URL:" to "https://myshibbolethserver.myinstitution.edu/idp/profile/SAML2/Redirect/SSO"
--Set the "Protocol Binding" to 'POST'
--Set "Request NameId Format" to "[Do Not Use]"
--Set the "Service Provider Name" to "NetPartner"
--Set the Public Key Certificate to the SSL certificate that is used to sign assertions in your shibboleth instance.  The default location for this is in ~shibboleth\idp\credentials\idp-signing.crt.
--Set the "After Log Out, take Students to URL" to whatever URL you wish your students to land on when they click on Logout.
--Click on the "Submit" button at the bottom of the page to activate your settings.


____ Testing your configurations ____

After the shibboleth settings have been completed, the tomcat service must be restarted.  Net Partner does not require a restart after submitting changes in the last section.  Monitor the shibboleth idp-process.log during tomcat startup to see if there are relevant WARN or ERROR entries.  If there are none, try logging into Net Partner Student with valid account.  You should be redirected to your shibboleth login page for your credentials.  If not, view the idp-process.log file for relevant entries.  Also, on the server that hosts the Net Partner web app, view the NPStudent.log file (default location:  C:\ProgramData\The College Board\PowerFaids\NPStudent.log).

If you require more verbose logs in shibboleth (for example to observe how your Student Identifier field is being resolved), edit the shibboleth logback.xml configuration file and set <variable name="idp.loglevel.idp" value="DEBUG" /> (be default the value is "INFO").  If necessary, enable debug with one of the other loglevel settings.  Be sure to change your settings back when you are through testing.


____ Concluding notes ____

Best wishes to you in configuring PowerFAIDS Net Partner for Shibboleth SSO.  For those of you who understand Shibboleth and SAML SSO better than I do, feel free to add comments.  If you have succeeded in getting Net Partner to work with more elegant settings, or or perhaps omitting settings I have that are not necessary, please post.

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.
> As promised, here is a summary of steps required to support Single Sign On
> (SSO) with SAML for the PowerFAIDS Net Partner web app using the Shibboleth
> 3.0 identity provider.

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

-- 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]
12