IdP3.4.7备份恢复及高可用方案

目前，因为IdP虚拟机或者服务器崩溃或者意外数据丢失等原因，陆续出现已经部署好的IdP服务中止运行的情况。建议采用如下方法对IdP进行备份，以便出现意外时快速恢复。

如果通过重新部署的方式对IdP进行升级，为了尽量减少线上服务的中断，建议准备另一套环境按照脚本方式安装部署CARSI IdP 3.4.7（此文档不再维护，不推荐使用）安装部署完成后，修改本地hosts文件，指向新环境进行IdP测试，测试正常再将DNS解析切到新的IdP上，切换DNS过程会短暂影响服务的运行。

1. metadata证书文件备份（重要，必做）

IdP服务的核心配置文件是metadata证书文件，因存放本校IdP通信证书等关键配置信息，必需定期保留。如果不保留，因各种原因进行IdP重装后，metadata发生改变，不仅需要将它重新上传至CARSI，更麻烦的是需要人工联系所有已经对接好的服务提供商进行metadata信息更新，等于需要重新完成一遍新IdP部署和服务开通流程。

如果提前保留了metadata证书文件，系统重装或者升级后，用原文件替换安装文件，服务可以直接运行。

1.1 备份

备份所有证书文件/opt/shibboleth-idp/credentials和idp.properties文件，具体包括：

序号	名称	用途

序号	名称	用途
1	dsmeta.pem	更新carsi metadata用到的证书
2	idp-backchannel.crt	metadata里面signing证书
3	idp-backchannel.key	metadata里面signing证书key
4	idp-backchannel.p12	signing证书的另一种格式
5	idp-encryption.crt	metadata里面encryption证书
6	idp-encryption.key	metadata里面encryption证书key
7	idp-signing.crt	metadata里面signing证书
8	idp-signing.key	metadata里面signing证书key
9	sealer.jks	idp自身使用用于加密cookies和其他数据
10	sealer.kver	idp自身使用用于加密cookies和其他数据
11	idp.properties	证书相关配置信息

1.2 新系统恢复原metadata证书文件的前提条件

按照wiki安装idp步骤对idp进行重装，至完全重装好后，属性定义、属性释放、认证对接均需要做完，同时确认已完成以下配置。

下载https://www.carsi.edu.cn/carsimetadata/carsifed-metadata.xml 文件，放入/opt/shibboleth-idp/metadata文件夹，并且修改文件的所属用户和组。

[root@www ~]# chown -R tomcat.tomcat /opt/shibboleth-idp
[root@www ~]# vi /opt/shibboleth-idp/conf/metadata-providers.xml
#修改之前定义的MetadataProvider
<MetadataProvider id="HTTPMetadata"
    xsi:type="FileBackedHTTPMetadataProvider"
    backingFile="/opt/shibboleth-idp/metadata/carsifed-metadata.xml"
    minRefreshDelay="PT5M"
    maxRefreshDelay="PT10M"
    metadataURL="https://www.carsi.edu.cn/carsimetadata/carsifed-metadata.xml"> 
    <MetadataFilter xsi:type="SignatureValidation" certificateFile="/opt/shibboleth-idp/credentials/dsmeta.pem" />
    <MetadataFilter xsi:type="EntityRoleWhiteList">
        <RetainedRole>md:SPSSODescriptor</RetainedRole>
    </MetadataFilter>
</MetadataProvider>
[root@www ~]# systemctl restart tomcat

1.3 新系统恢复原metadata文件

1) 用备份的/opt/shibboleth-idp/credentials覆盖新安装好的idp的/opt/shibboleth-idp/credentials里面的所有文件，替换之后，修改文件的所有者。

[root@www ~] chown -R tomcat.tomcat /opt/shibboleth-idp/credentials

如果新系统安装过程中”后台证书密码“和”Cookie加密密码“与老系统不一致，需修改idp.properties文件的如下两个参数。参数取值，可在老系统的idp.properties文件查询。

idp.sealer.storePassword={修改为老系统的后台证书密码}
idp.sealer.keyPassword={修改为老系统的Cookie加密密码密码}

如果新系统安装过程中”后台证书密码“和”Cookie加密密码密码“与老系统不一致，修改idp.properties文件。

2) 删除新的idp安装过程中产生的metadata，并生成与重装前一致的metadata

[root@www ~] rm -rf /opt/shibboleth-idp/metadata/idp-metadata.xml
[root@www ~] cd /opt/shibboleth-idp/bin
[root@www ~] ./ant.sh metadata-gen -Didp.host.name=(填写idp域名，与原域名一致)
[root@www ~] chown -R tomcat.tomcat /opt/shibboleth-idp/metadata
[root@www ~] rm -rf /etc/httpd/conf.d/idp8443.conf

3) 重启tomcat和nginx

[root@www ~] systemctl restart httpd
[root@www ~] systemctl restart nginx

1.4 测试

访问ds.carsi.edu.cn，选择学校名称，检查IdP是否能够认证成功。具体参见上线后验证部分。

2. eduPersonTargtedID加密盐值备份（重要，必做）

eduPersonTargtedID是一个永久可用的用户唯一id。通过hash算法加密之后，可读性不强。适用于需要区分不同用户的应用场景，同时保护了用户个人隐私。为了保证重装后每个用户生成的eduPersonTargtedID一致，需要对加密盐值进行备份。

采用数据库方式安装的IdP，加密盐值位置在/opt/shibboleth-idp/conf/saml-nameid.properties文件中的idp.persistentId.salt = xxxxxxxxxxxxxxxxxxxx

未采用数据库方式安装的IdP，加密盐值位置在/opt/shibboleth-idp/conf/attribute-resolver.xml文件中的salt="xxxxxxxxxxxxxxxxxxxx"

请将盐值保留好或者将配置文件进行整体备份

<AttributeDefinition id="eduPersonTargetedID" xsi:type="SAML2NameID" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    <InputDataConnector ref="ComputedIDConnector" attributeNames="computedID"/>
    <AttributeEncoder xsi:type="SAML1XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" encodeType="false"/>
    <AttributeEncoder xsi:type="SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" encodeType="false"/>
</AttributeDefinition>
<DataConnector id="ComputedIDConnector" xsi:type="ComputedId" generatedAttributeID="computedID" salt="xxxxxxxxxxxxxxxxxxxx" encoding="BASE64">
    <InputAttributeDefinition ref="eduPersonPrincipalName" />
</DataConnector>

3. 服务器运行数据的备份

2.1.虚机的备份（适用于虚机部署的情况，建议）

使用vmware exsi虚拟化平台部署的IdP，建议定期对虚拟机进行备份，例如将虚拟机定期拷贝到另一台esxi主机或者独立的存储介质上。意外发生时，直接将备份的虚机恢复到exsi主机上启动即可恢复服务运行。

2.2.数据的备份及恢复

如果使用ova镜像部署的话，在IdP服务器里，定期对/opt/shibboleth-idp文件夹进行压缩，对关键运行数据进行备份。

#将/opt/shibboleth-idp进行打包压缩成/opt/shibboleth-idp.tar.gz文件
[root@www~]cd /opt/
[root@www~]tar -zcvf shibboleth-idp.tar.gz shibboleth-idp

当发生意外的时候，将备份的数据直接解压缩到新的ova镜像服务器/opt/shibboleth-idp上即可恢复服务运行。

#将shibboleth-idp.tar.gz文件上传至新的ova镜像/opt路径下
[root@www~]cd /opt/
[root@www~]tar -zxvf shibboleth-idp.tar.gz
[root@www~]chown -R tomcat.tomcat /opt/shibboleth-idp
#重启tomcat和apache
[root@www~]systemctl restart tomcat
[root@www~]systemctl restart httpd

3.依托负载均衡提高服务可用性

另一种方案是部署两台一模一样的idp服务器，也可以部署好一台后直接镜像拷贝成另外一台。前面用F5或者nginx进行负载均衡。这样如果有一台发生意外的话，另一台还能继续工作，保证idp服务不间断。此种方式好处是可以动态的增加或者删减idp服务器。

以nginx负载均衡为例，以下配置仅供参考，如何将idp服务器修改成8080端口提供服务，请参考反向代理对接。

upstream name {
       ip_hash; 
       #xxx.xxx.xxx.xxx表示idp服务器的ip地址
       server xxx.xxx.xxx.xxx:8080;
       server xxx.xxx.xxx.xxx:8080;
       #检查服务器是否存活
       check interval=3000 rise=2 fall=5 timeout=1000 type=http;
}

server {
        #xxx.xxx.xxx.xxx表示idp域名
        server_name  xxx.xxx.xxx.xxx;
        listen       443 ssl;
        listen       [::]:443 ssl;
        root    /var/www/html/dspre;
        
        ssl_protocols TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDHE+RSAGCM:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!aNULL!eNull:!EXPORT:!DES:!3DES:!MD5:!DSS;
        #xxxx表示域名证书和key的绝对路径
        ssl_certificate      xxxx;
        ssl_certificate_key  xxxx;

        include /etc/nginx/default.d/*.conf;

        location / {
           proxy_pass http://name;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
        }

    }