WG: Problem with urn:oasis:names:tc:SAML:2.0:na
|
|||||||||||||||||||||||||
![]()
WG: Problem with urn:oasis:names:tc:SAML:2.0:na
|
Hello Guys!
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, -- For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg To unsubscribe from this list send an email to [hidden email] |
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] |
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.
<resolver:AttributeEncoder xsi:type="SAML1String"
<resolver:AttributeEncoder xsi:type="SAML2String" <!-- for including the persistent NameID in the response --> <resolver:AttributeEncoder <resolver:AttributeEncoder xsi:type="SAML2StringNameID" But i think, i must „translate“ the code in saml-nameid.xml?
Greetings from Vienna, Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Phil, If you reply to this email, your message will be added to the discussion below: To unsubscribe from Shibboleth - Users,
click here. -- For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg To unsubscribe from this list send an email to [hidden email] |
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] |
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, Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Phil, If you reply to this email, your message will be added to the discussion below: To unsubscribe from Shibboleth - Users,
click here. -- For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg To unsubscribe from this list send an email to [hidden email] |
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] |
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? Phil Von: Nate Klingenstein-5 [via Shibboleth] <ml+[hidden email]>
Phil, If you reply to this email, your message will be added to the discussion below: To unsubscribe from Shibboleth - Users,
click here. -- For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg To unsubscribe from this list send an email to [hidden email] |
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] |
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]>
Phil, If you reply to this email, your message will be added to the discussion below: To unsubscribe from Shibboleth - Users,
click here. -- For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg To unsubscribe from this list send an email to [hidden email] |
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] |
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] |
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] |
Free forum by Nabble | Edit this page |