@tkimnguyen Given that it is itself forked from the GWW version (I think), I have no problem with it. There are some code changes in it that I believe are more specific to the solution that Jazkarta needed for a particular client, but they point at some control panel functionality that would be useful more globally for other clients.
thx - ok, it is forked now to https://github.com/collective/dm.zope.saml2 and the issue tracker has been enabled
It looks like an error reported by "PyXB" - for the case, that a (XML-schema) namespace is referenced without "PyXB" knowing the corresponding schema.
In principle, collective.saml2 is supposed to make all namespaces used by ADFS known; however, the SAML metadata description may in your case use an extension, not normally used by ADFS, and then you can get such an error.
1 Like
Thanks Dieter.
I have been checking my federationmetadata.xml file and it looks like it doesn't use any extension. I have looked into the file and there is no reference to the stated typeBinding thing.
I have also googled for some other sample federationmetadata files, just to check if they worked, and haven't made to work any of the files found, I always get the same typeBinding error.
Our client is using ADFS 3.0.
Any other hint will be appreciated,
Mikel
I live on a MS free island and cannot say much about MS integration. As author of dm.saml2 and dm.zope.saml2, I can say provide some general information.
My "saml2" modules are based on PyXB. This is a subframework for XML-Schema handling (a standard, SAML2 heavily depends upon). It can create a Python class for an XML-Schema (called a binding) and then parse a schema compliant XML document into an instance of this class or serialize such an instance into a schema compliant XML document. In order for the parsing to work, PyXB must have a type binding (i.e. the corresponding Python class) for each XML-schema referenced by the XML document.
In your case, the metadata XML document apparently references an XML-Namespace for which PyXB does not yet have a corresponding Python class (i.e. the corresponding type binding).
dm.saml2 (in fact PyXB) comes with the type bindings typically used by (pure) SAML2. It knows nothing about MS specific extensions, however. It is not difficult to use PyXB to generate new type bindings and make them available for later parsing. Dylan has done this in collective.saml2 to get ADFS support. I cannot tell you why it does not work in your case: maybe, you are not using collective.saml2; maybe, you missed some installation step for it; maybe, your ADFS version uses another XML-schema (not yet handled by collective.saml2).
Actually I didn't generate new bindings in c.saml2. I did some other fixes like avoiding the use of sessions.
@lewy I believed did the PyXB think to created compatibility with Office365 but not ADFS. It would be great however to have tested ADFS compatibility.
Actually the whole purpose of forking was to make it work with ADFS. I don't recall details at the moment, but we probably generated new bindings for PyXB. I'm not sure if that part was published - I'll check with my colleagues.
We're about to build this for a customer of ours. Like @jensens , i feel python-saml looks like the better choice.
@dieter As a side note, i see there are 9 forks of dm.xmlsec.binding on github: https://github.com/search?q=dm.xmlsec.binding
It must be nice to see so many people using your module! But maybe it would make sense to put the original repo, with history, on github?
I've struggling for this trasparent authentication between Plone and Pc's, I as well got succes with pas.plugins.ldap, now I'm trying the netsight.windowsauthplugin too, I didin't got major errors while instaling it eccept for these:
Error while compiling /opt/plone/buildout-cache/eggs/python_gettext-3.0-py2.7.egg/pythongettext/tests/test_escape.po
Error while compiling /opt/plone/buildout-cache/eggs/python_gettext-3.0-py2.7.egg/pythongettext/tests/test5.po
But as found here in the community I didin't concerned about it.
To set up netsight.windowsauthplugin I followed this article: https://github.com/netsight/netsight.windowsauthplugin and the slides and video told before.
But when trying the authentication nothing happens, in firefox I got nothing an with chrome and ie I got this:
2017-11-30T15:48:23 INFO SPNEGO plugin 127.0.0.1: Attempted to use unsupported NTLM auth
Please I appreciate so much some guidance.
Did you look for this error message online? I vaguely remember seeing this as well: what I think happens is that the kerberos authentication does not start on your client at all or fails, and as a fallback the client tries to do an alternative microsoft authentication called NTLM, which isn't supported by the plugin.
I installed the collective/dm.zope.saml2, but I cannot seem to find the configuration pages. Can someone please guide me through getting this thing to work with Shibboleth/SAML2?
Read the documentation of dm.zope.saml2 on "PyPI". You will also need an elementary understanding of SAML2, especially the concepts of "SAML2 authority" and "SAML2 roles" and further "SAML2 metadata".
With dm.zope.saml2, an SAML2 authority is represented by a corresponding object (which you create using the ZMI (= Zope Management Interface)). SAML2 roles, too, are represented by corresponding objects. When you create those objects, the corresponding "add form"s allow you to provide configuration parameters (some of which can later be changed, if necessary). Typically, those objects are created at the top level of the Plone portal. An exception is the PAS plugin; it is created below acl_users; this applies as well when the plugin integrates the SP (= Service Provider) role.
Also read https://github.com/collective/collective.saml2.
That has more documentation and installing collective.saml2 does one extra step for you which requires a code change when using dm.saml2 directly.
This is 4 years old, would it work with Plone 5?
Yes it does
Not sure what your "it" refers to.
If it refers to dm.zope.saml2 (and derivatives), there is a good chance that it will work with Plone 5: it is mostly backend functionality - unaffected by the huge changes regarding resources and presentation in Plone 5. The remaining part is configuration, build on top of "five.formlib" independent of Plone.
But, I do not know whether there are unanticipated problems when used with Plone 5. Should someone find some (and report them to me), I will look into them.
The main thing I ran into was the default charset encoding. I've fixed this in the collective repo.
Maybe this is something you could look into and release?