Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Uppgraderingen till Shibboleth IdPv4 är lite mer komplicerad än en vanlig uppgradering av Shibboleth. Innan man uppgradera till v4, måste man ha redan anpassat konfigurationsfilerna till den nya versionversionen

Om din IdP version är under v3.4 så måste du uppgradera till senaste 3.4 version först. De här instruktionerna är testad på IdPer på version 3.4.6.

...

Du måste ha uppdaterat dina konfigurationsfiler (särskilt attribute-resolver.xml och attribute-filter.xml) till att vara kompatibla med IdP v3.4 och v4 innan du påbörjar uppgradering. Kontrollera loggfilerna för att säkerställa att inga DEPRECATED varningar förekommer. Alla varningar måste lösas innan uppgradering till v4. De flesta DEPRECATED varningar förekommer på grund av legacy (IdP v2) konfiguration i attribute-resolver och attribute-filter. De nya standard attribute-resolver och attribute-filter filer finns här: 

Example of a standard attribute resolver for Shibboleth IdP v3.4.0 v4 and above och Example of a standard attribute filter for Shibboleth IdP v3.4.0 and above

...

Vi har sett att det finns äldre versioner av httpcore, httpclient, commons-dbcp2, commons-pool2 under mapp /opt/shibboleth-idp/edit-webapp/WEB-INF/lib. Om du har dessa jar-filer i /opt/shibboleth-idp/edit-webapp/WEB-INF/lib, ta bort dem. Nyare versioner finns med i Shibboleth IdPv4

Följande legacy delen av web.xml som idp-installern la till en gång i tiden verkar orsaker problem för nya Jetty. Rekommendationen är att kommentera bort hela security-constraint och login-config som visas nedan (om de finns)

Code Block
languagexml
titleDelar av web.xml som eventuellt behöver kommenteras bort
collapsetrue
 <!-- IdP-installer has appended these settings to the config which uncomments entries documented above -->
 <!--
    Uncomment to use container managed authentication. The new servlet spec (3.1)
    supports "**" as a wildcard syntax to avoid role usage, which is normally desirable.
    Older containers usually support "*" when proprietary options are used (e.g., Jetty
    requires setting the Strict property on the SecurityManager.)
    -->
    <security-constraint>
        <display-name>Web Login Service</display-name>
        <web-resource-collection>
            <web-resource-name>user authentication</web-resource-name>
            <url-pattern>/Authn/RemoteUser</url-pattern>
            <url-pattern>/profile/SAML2/SOAP/ECP</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>**</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

 <!-- Uncomment if you want BASIC auth managed by the container. -->
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>ShibUserPassAuth</realm-name>
    </login-config>

MySQL Connector och HikariCP jar-filer

...