WG: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

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

WG: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth@pnem.at
Hello Guys!


i have some Problems and hope, you can help me!
We are testing for your Applicaton IDP4 with Tomcat9 and all look good, but i get this Messages:


2021-01-09 15:23:47,561 - 10.10.26.0 - WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:334] - Profile Action AddNameIDToSubjects: Request specified use of an unsupportable identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
2021-01-09 15:23:47,571 - 10.10.26.0 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: InvalidNameIDPolicy

==> idp-process.log <==
2021-01-09 15:23:47,571 - 10.10.26.0 - WARN [org.opensaml.profile.action.impl.LogEvent:101] - A non-proceed event occurred while processing the request: InvalidNameIDPolicy

we use the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent - format, but i have no idea where is should looking for the Problem....


attribute-resolver.xml


<AttributeResolver
        xmlns="urn:mace:shibboleth:2.0:resolver"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd">
    <AttributeDefinition id="uid" xsi:type="PrincipalName">
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false" />
    </AttributeDefinition>
    <DataConnector id="staticAttributes" xsi:type="Static">
        <Attribute id="affiliation">
            <Value>member</Value>
        </Attribute>

saml-nameid.xml

   <util:list id="shibboleth.SAML2NameIDGenerators">

        <ref bean="shibboleth.SAML2TransientGenerator" />
        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
        p:omitQualifiers="true"
        p:format="urn:oid:0.9.2342.19200300.100.1.1"
        p:attributeSourceIds="#{ {'uid'} }" />
        <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
        <!--
                     <ref bean="shibboleth.SAML2PersistentGenerator" />
        -->


        <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
            p:attributeSourceIds="#{ {'uid'} }" />


    </util:list>

    <!-- SAML 1 NameIdentifier Generation -->
    <util:list id="shibboleth.SAML1NameIdentifierGenerators">

        <ref bean="shibboleth.SAML1TransientGenerator" />

        <!--
        <bean parent="shibboleth.SAML1AttributeSourcedGenerator"
            p:omitQualifiers="true"
            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
            p:attributeSourceIds="#{ {'mail'} }" />
        -->

    </util:list>

</beans>

The Connection to the LDAP - Server (Microsoft AD) looks good and after hours reading the xml/codes i have no idea :-(

Greetings,
Phil


--
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: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

Nate Klingenstein-5
Phil,

Odds are that you haven't configured your IdP to be able to send persistent nameID's:

> 2021-01-09 15:23:47,561 - 10.10.26.0 - WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:334] - Profile Action AddNameIDToSubjects: Request specified use of an unsupportable identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

As indicated by your snippet of saml-nameid.xml.

>         <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
>
>         <!--
>
>                      <ref bean="shibboleth.SAML2PersistentGenerator" />
>
>         -->

As such, the IdP is unable to generate the requested NameID format and meet the policy requirements of the SP with which it's attempting to communicate, causing it to error out.  You'll need to follow the appropriate steps to enable the generation of persistent NameID's.  It's a slightly tricky topic, so be sure to follow the documentation closely.

https://wiki.shibboleth.net/confluence/display/IDP4/PersistentNameIDGenerationConfiguration

If the service actually requires persistent NameID's, then you'll need to go through full configuration and understanding of them.  If it doesn't and it's misusing the standard(which is fairly common in deployment), then you can put a hack in place(ill-advised in most cases), or reconfigure the service's metadata/AuthnRequest to require a different NameID format.

Best wishes,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

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

AW: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth@pnem.at

Hello Nate,

 

first of all – thank you very much for your answer!

Our Application use urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and i think you are right, the IDP cant handle it.


I think you are right, the saml-nameid.xml ist not correct oft that.


With IDP2 our Configuration was this:

  <resolver:AttributeEncoder xsi:type="SAML1String"
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:mace:dir:attribute-def:userPrincipalName" />

  <resolver:AttributeEncoder xsi:type="SAML2String"  
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    name="urn:oid:1.2.840.113556.1.4.656"  
    friendlyName="userPrincipalName" />

  <!-- for including the persistent NameID in the response -->

  <resolver:AttributeEncoder
    xsi:type="SAML1StringNameIdentifier"
    xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
    nameFormat="urn:mace:shibboleth:1.0:nameIdentifier" />

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

But i think, i must „translate“ the code in saml-nameid.xml?

 

Greetings from Vienna,
Phil

 

 

Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Gesendet: Samstag, 9. Jänner 2021 19:03
An: [hidden email]
Betreff: RE: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

 

Phil,

Odds are that you haven't configured your IdP to be able to send persistent nameID's:

> 2021-01-09 15:23:47,561 - 10.10.26.0 - WARN [org.opensaml.saml.saml2.profile.impl.AddNameIDToSubjects:334] - Profile Action AddNameIDToSubjects: Request specified use of an unsupportable identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

As indicated by your snippet of saml-nameid.xml.

>         <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
>
>         <!--
>
>                      <ref bean="shibboleth.SAML2PersistentGenerator" />
>
>         -->

As such, the IdP is unable to generate the requested NameID format and meet the policy requirements of the SP with which it's attempting to communicate, causing it to error out.  You'll need to follow the appropriate steps to enable the generation of persistent NameID's.  It's a slightly tricky topic, so be sure to follow the documentation closely.

https://wiki.shibboleth.net/confluence/display/IDP4/PersistentNameIDGenerationConfiguration

If the service actually requires persistent NameID's, then you'll need to go through full configuration and understanding of them.  If it doesn't and it's misusing the standard(which is fairly common in deployment), then you can put a hack in place(ill-advised in most cases), or reconfigure the service's metadata/AuthnRequest to require a different NameID format.

Best wishes,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

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


To unsubscribe from Shibboleth - Users, click here.
NAML


--
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: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

Nate Klingenstein-5
Phil,

> But i think, i must „translate“ the code in saml-nameid.xml?

You could probably come up with a very awkward way to make it backward compatible with the older configuration, but that would be a really bad idea.  The newer implementation does much better database locking and other things for you.  I would strongly recommend that you use the native support in IdPv4 instead of trying to go through the attribute resolver.

So, yes, that means basically "translating" what you have in the attribute resolver now into saml-nameid.xml and saml-nameid.properties.

> Greetings from Vienna,

I have never been, and I would love to see it someday.  Warm welcomes back from a cold mountain town in Colorado, and always glad to help.

Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id
--
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
|

AW: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth@pnem.at

Hi Nate,

 

my goal is that we „transalte“ the old code in the new one. So i transfer  the Infos to the saml-nameid.xml and saml-nameid.properties.

 

Do you have some Tips to translate the code? Need i translate to the attribute-filter and attribute-resolver?

 

Greetings,
Phil

PS: Greetings to Colorado! Next Travel i planning to Montana or Southern States.

 

Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Gesendet: Samstag, 9. Jänner 2021 20:52
An: [hidden email]
Betreff: RE: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

 

Phil,

> But i think, i must „translate“ the code in saml-nameid.xml?

You could probably come up with a very awkward way to make it backward compatible with the older configuration, but that would be a really bad idea.  The newer implementation does much better database locking and other things for you.  I would strongly recommend that you use the native support in IdPv4 instead of trying to go through the attribute resolver.

So, yes, that means basically "translating" what you have in the attribute resolver now into saml-nameid.xml and saml-nameid.properties.

> Greetings from Vienna,

I have never been, and I would love to see it someday.  Warm welcomes back from a cold mountain town in Colorado, and always glad to help.

Nate.

--------
Signet, Inc.
The Art of Access ®

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


To unsubscribe from Shibboleth - Users, click here.
NAML


--
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: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

Nate Klingenstein-5
Phil,

> Do you have some Tips to translate the code? Need i translate to the attribute-filter and attribute-resolver?

Just use the same database settings or salt that you were using earlier, although you'll want to update any database driver too, if it's as old as IdPv2. ;)  It really isn't too complicated.  You shouldn't need anything in the attribute filter because this is only being sent as a NameID and is not being sourced as an attribute, but instead as a special kind of name identifier.

Take care,
Nate.
--
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
|

AW: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth@pnem.at

Hi Nate,

 

so for the record.

 

we have the IDP4 in a combination with a Microsoft AD LDAP. We want to use the AD users.

So – when i understand  you right – i just configuration the saml-nameid*xml/properties File to create the SAML2PersistentGenerator for my IDP?

Thank you very much,

Phil

 

Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Gesendet: Samstag, 9. Jänner 2021 21:04
An: [hidden email]
Betreff: RE: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

 

Phil,

> Do you have some Tips to translate the code? Need i translate to the attribute-filter and attribute-resolver?

Just use the same database settings or salt that you were using earlier, although you'll want to update any database driver too, if it's as old as IdPv2. ;)  It really isn't too complicated.  You shouldn't need anything in the attribute filter because this is only being sent as a NameID and is not being sourced as an attribute, but instead as a special kind of name identifier.

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


To unsubscribe from Shibboleth - Users, click here.
NAML


--
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: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

Nate Klingenstein-5
Phil,

If you only have AD and you don't have a database available to you, you'll need to use the hash-based Computed ID solution, and if your salt is different from the old one, all the associations made with all SP's using persistent NameID's will break.  That's about all.

So, yes, just uncomment the persistent generation bean in saml-nameid.xml and configure the appropriate properties in saml-nameid.properties, and clean up the old configuration in attribute-filter.xml and attribute-resolver.xml.

Best regards,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

> so for the record.
>
> we have the IDP4 in a combination with a Microsoft AD LDAP. We want to use the AD users.
>
> So – when i understand  you right – i just configuration the
> saml-nameid*xml/properties File to create the SAML2PersistentGenerator for my IDP?

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

AW: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

philip.nemeth@pnem.at

Nate,

 

thank you very much for your time.

 

okay i will try it on Monday.

And that our Application use urn:oasis:names:tc:SAML:2.0:nameid-format:persistent should no Problem too with this?

 

From our Documentation:

 

„……….. where LDAP is used as authentication backend and the user principal name gets embedded in the NameID tag of the assertion. This example includes attribute encoders which entails that the name identification gets sent the NameID tag of the response and additionally in an attribute with the name urn:oid:1.2.840.113556.1.4.656.“

 

Greetings,

Phil

 

 

Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Gesendet: Samstag, 9. Jänner 2021 21:37
An: [hidden email]
Betreff: RE: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

 

Phil,

If you only have AD and you don't have a database available to you, you'll need to use the hash-based Computed ID solution, and if your salt is different from the old one, all the associations made with all SP's using persistent NameID's will break.  That's about all.

So, yes, just uncomment the persistent generation bean in saml-nameid.xml and configure the appropriate properties in saml-nameid.properties, and clean up the old configuration in attribute-filter.xml and attribute-resolver.xml.

Best regards,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

> so for the record.
>
> we have the IDP4 in a combination with a Microsoft AD LDAP. We want to use the AD users.
>
> So – when i understand  you right – i just configuration the
> saml-nameid*xml/properties File to create the SAML2PersistentGenerator for my IDP?

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


To unsubscribe from Shibboleth - Users, click here.
NAML


--
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: Problem with urn:oasis:names:tc:SAML:2.0:nameid-format:persistent?

Nate Klingenstein-5
Phil,

It depends entirely on how the applications are designed.  If they(or their SPs) are only looking for an attribute, especially with a URN reserved for userPrincipalName, they're not going to find it.  If they're looking for a NameID with the same URN, they will.  If they were looking for either, they're fine.

A Shibboleth configuration can map them to the same environment variable, so applications wouldn't even notice the change.

If you were just looking for userPrincipalName in your applications or SP's, then the best realistic option is to pull that attribute from the directory and send it using the attribute resolver and attribute filter, and get rid of anything related to persistentID's in metadata and your AuthnRequests.  If you're trying to send userPrincipalName as a persistentID, that's not an appropriate use of the specification, but you would do it with an attribute-based NameID generator and an attribute definition and release filter, similar to what was in your original email for other attributes and the unspecified format.

So, nobody can answer that question except for you.

Take care,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

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

sp can not get metadata from idp

malanxin
Hello,

My SP cannot get metadata from IDP.
My SP version is 3.1.0, Apache version is 2.4.6. My IDP version is 2.4.1

rpm -qa | grep shib
shibboleth-3.1.0-3.1.x86_64
liblog4shib2-2.0.0-3.1.x86_64

rpm -qa | grep httpd
httpd-tools-2.4.6-93.el7.centos.x86_64
httpd-2.4.6-93.el7.centos.x86_64

Here is the error log  in /var/log/shibboleth/shibd.log at SP

2021-01-11 17:21:22 INFO Shibboleth.Application : building MetadataProvider of type XML...
2021-01-11 17:21:22 ERROR XMLTooling.libcurl.InputStream : error while fetching https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML: (59) Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
2021-01-11 17:21:22 ERROR XMLTooling.libcurl.InputStream : on Red Hat 6+, make sure libcurl used is built with OpenSSL
2021-01-11 17:21:22 ERROR XMLTooling.ParserPool : fatal error on line 0, column 0, message: internal error in NetAccessor
2021-01-11 17:21:22 ERROR OpenSAML.MetadataProvider.XML : error while loading resource (https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML): XML error(s) during parsing, check log for specifics
2021-01-11 17:21:22 WARN OpenSAML.MetadataProvider.XML : adjusted reload interval to 600 seconds
2021-01-11 17:21:22 WARN OpenSAML.MetadataProvider.XML : trying backup file, exception loading remote resource: XML error(s) during parsing, check log for specifics

Hereis my SP config
cat /etc/shibboleth/shibboleth2.xml
    <ApplicationDefaults entityID = "https://a.ihep.ac.cn/shibboleth"
        REMOTE_USER="eppn subject-id pairwise-id persistent-id"
        cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1"
        encryption="false">
            <SSO entityID="https://idp-test.ihep.ac.cn/idp/shibboleth" >
              SAML2 SAML1
            </SSO>

        <MetadataProvider type="XML" validate="true"
        url="https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML"
        backingFilePath="idp-test-metadata.xml" maxRefreshDelay="7200">
        </MetadataProvider>

I do not understand.  What cause the problem. Could any body help ?
Thanks a lt,

Best Regards,
Lanxin

--
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: sp can not get metadata from idp

Nate Klingenstein-5
Lanxin,

The versions of software that you're using are old.  Your IdP version in particular is very unsupported, and I don't know RedHat's complete deprecation schedule immediately or which version you're using.

Anyway, RedHat made the decision between versions 5 and 6 to switch from using OpenSSL as its cryptographic library for libcurl to using NSS.  This gave Shibboleth much more limited ability to control the network layer when establishing connections, so the project had to switch to distributing a version libcurl built against OpenSSL along with the SP, for RHEL 6 and 7.  RedHat reverted this change in RHEL 8, so it's no longer necessary with the most recent software.

https://wiki.shibboleth.net/confluence/display/SP3/LinuxRH6

You will need to make sure the SP is built and linked against a libcurl built against OpenSSL, and you should upgrade a lot of software to modern releases.

At that point, the network calls should work.  Your configuration looks okay.

谢谢啦,
Nate.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

 
 
-----Original message-----

> From: MA Lanxin
> Sent: Monday, January 11 2021, 2:47 am
> To: shib users
> Subject: sp can not get metadata from idp
>
> Hello,
>
> My SP cannot get metadata from IDP.
> My SP version is 3.1.0, Apache version is 2.4.6. My IDP version is 2.4.1
>
> rpm -qa | grep shib
> shibboleth-3.1.0-3.1.x86_64
> liblog4shib2-2.0.0-3.1.x86_64
>
> rpm -qa | grep httpd
> httpd-tools-2.4.6-93.el7.centos.x86_64
> httpd-2.4.6-93.el7.centos.x86_64
>
> Here is the error log  in /var/log/shibboleth/shibd.log at SP
>
> 2021-01-11 17:21:22 INFO Shibboleth.Application : building MetadataProvider of type XML...
> 2021-01-11 17:21:22 ERROR XMLTooling.libcurl.InputStream : error while fetching https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML: (59) Unknown cipher in list: ALL:!aNULL:!LOW:!EXPORT:!SSLv2
> 2021-01-11 17:21:22 ERROR XMLTooling.libcurl.InputStream : on Red Hat 6+, make sure libcurl used is built with OpenSSL
> 2021-01-11 17:21:22 ERROR XMLTooling.ParserPool : fatal error on line 0, column 0, message: internal error in NetAccessor
> 2021-01-11 17:21:22 ERROR OpenSAML.MetadataProvider.XML : error while loading resource (https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML): XML error(s) during parsing, check log for specifics
> 2021-01-11 17:21:22 WARN OpenSAML.MetadataProvider.XML : adjusted reload interval to 600 seconds
> 2021-01-11 17:21:22 WARN OpenSAML.MetadataProvider.XML : trying backup file, exception loading remote resource: XML error(s) during parsing, check log for specifics
>
> Hereis my SP config
> cat /etc/shibboleth/shibboleth2.xml
>     <ApplicationDefaults entityID = "https://a.ihep.ac.cn/shibboleth"
>         REMOTE_USER="eppn subject-id pairwise-id persistent-id"
>         cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1"
>         encryption="false">
>             <SSO entityID="https://idp-test.ihep.ac.cn/idp/shibboleth" >
>               SAML2 SAML1
>             </SSO>
>
>         <MetadataProvider type="XML" validate="true"
>         url="https://idp-test.ihep.ac.cn/idp/profile/Metadata/SAML"
>         backingFilePath="idp-test-metadata.xml" maxRefreshDelay="7200">
>         </MetadataProvider>
>
> I do not understand.  What cause the problem. Could any body help ?
> Thanks a lt,
>
> Best Regards,
> Lanxin
>
> --
> 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]