This is a third party addition: the original dm.zope.saml2.util does not contain a function getCharset (and this is as it should be -- as a getCharset function has nothing to do with SAML2).
Ah, I think it got inlined because Products.PlonePAS.utils no longer provided getCharset, which is used in the original.
How would you like to receive patches?
Via email (to dieter at handshake dot de) as context diff, if possible with an explanation why the change has been necessary.
Regarding getCharset: Products.PlonePAS no longer providing it might indicate that Plone not longer needs it. A comment around the usage of getCharset reminds me that I was quite unhappy to have been forced to use it because Plone could not cope with unicode properties - maybe, modern Plone versions have removed this limitation?
I plan to replace getCharset by an adapter. The default will be 'utf-8' which seems adequate for most, and especially most modern Plone portals. Portals which use a different charset will need to register their own adapter.
Did you make other modifications to obtain Plone 5 compatibility?
+1 for the adapter. About the default charset it might be interesting to have a registry record or to reuse an existing one (like it is done for plone.email_charset).
Not for Plone 5 compat.
I can mail you the other changes I did, or you can see them at https://github.com/collective/dm.zope.saml2/commits/master . I'd really like to see the 'Redirect to portal root in explicit login' bit as well.
Can you elaborate on this (maybe via personal email to dieter at handshake.de): in principle, dm.zope.saml2 should have nothing to do with the login itself; as identity provider, it delegates to the Plone login facility; as service provider, it integrates as a plugin and all other details should be handled by acl_users and its infrastructure.
Note, I will soon be on holidays and not respond for some weeks.
So I installed the wrapper (https://github.com/collective/collective.saml2) and the first step #1 is "In the ZMI Add at the Plone root a "Saml authority" object."
And as soon as I try to add it I get:
((<zope.schema._field.ASCIILine object at 0x7f8797abac90>, <HTTPRequest, URL=http://10.55.1.59:8080/manage_addProduct/dm.zope.saml2/add_SamlAuthority>), <InterfaceClass zope.formlib.interfaces.IInputWidget>, u'')
I have no idea what to do. Is there a step before this that is omitted in the docs? Do I need to add some custom code before installing this through buildout? I already have my shibboleth idp and want to set this plone site as service provider.
This is an incompleteness in the ZCML registrations for dm.zope.saml2: it depends on five.formlib, but does not include it. Former Plone versions hat five.formlib included; this has hidden the problem. Plone 5 replaced zope.formlib by z3c.form and therefore no longer needs five.formlib. Now, dm.zope.saml2 should include it itself.
Add five.formlib to the "zcml" definition in your buildout.cfg and rerun bin/buildout. This will fix your current problem (more minor Plone 5 incompatibilities might pop up later).
Thank you, that fixed it. But now I have another issue... when I add the saml authority any url that I put for base url I get this error:
2018-04-03 18:38:03 ERROR Zope.SiteErrorLog 1522780683.110.241231451423 http://10.55.1.59:8080/manage_addProduct/dm.zope.saml2/add_SamlAuthority
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module dm.zope.schema.z2.constructor, line 126, in add_form
Module zope.formlib.form, line 795, in __call__
Module five.formlib.formbase, line 50, in update
Module zope.formlib.form, line 776, in update
Module zope.formlib.form, line 620, in success
Module zope.formlib.form, line 896, in handle_add
Module zope.formlib.form, line 903, in createAndAdd
Module dm.zope.schema.z2.constructor, line 68, in add
Module OFS.ObjectManager, line 358, in _setObject
Module zope.event, line 31, in notify
Module zope.component.event, line 24, in dispatch
Module zope.component._api, line 136, in subscribers
Module zope.component.registry, line 321, in subscribers
Module zope.interface.adapter, line 585, in subscribers
Module zope.component.event, line 32, in objectEventNotify
Module zope.component._api, line 136, in subscribers
Module zope.component.registry, line 321, in subscribers
Module zope.interface.adapter, line 585, in subscribers
Module dm.zope.saml2.authority, line 360, in move_handler
ValueError: need a persistent active site
Does it have to be in a certain format? for example does it need http:// or a port number?
EDIT: any combination of http, https, slashes, and ports seems to throw the same error 
Are you sure that you try to add the SAML authority object inside a Plone portal?
dm.zope.saml2 objects need to interoperate with one another. For this, the SAML authority registers itself as a ZCA (= "Zope Component Architecture") utility. As it has configuration inside the ZODB, it must use a so called "local utility". Local utilities are managed by what the ZCA calls a "site". The error happens because the creation for the SAML authority does not find such a site.
A Plone portal registers typically a lot of local utilities. Therefore, it, too, has need of such a site - and sets itself up that it can function as a site. This means that you likely try to create the SAML authority outside of a Plone portal.
1 Like
That was it, thank you. My problem was that I was trying to add the saml auth to the root level.
As soon a "saml authority" is added, then the left menu in zmi breaks and debug screen shows:
2018-04-04 09:10:14 ERROR Zope.SiteErrorLog 1522847414.510.647831750464 http://localhost:8083/manage_menu
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Shared.DC.Scripts.Bindings, line 322, in __call__
Module Shared.DC.Scripts.Bindings, line 359, in _bindAndExec
Module App.special_dtml, line 185, in _exec
Module TreeDisplay.TreeTag, line 112, in render
Module TreeDisplay.TreeTag, line 233, in tpRender
Module TreeDisplay.TreeTag, line 490, in tpRenderTABLE
- __traceback_info__: ([u'AAAAAAAAAAE=', [[u'AAAAAAAAABU=', [[u'AAAAAAAAACU=']]]]], {'url': 'tpURL', 'nowrap': '1', 'branches': 'tpValues', 'id': 'tpId', 'childless_decoration': ''}, [[u'AAAAAAAAAAE=', [[u'AAAAAAAAABU=', [[u'AAAAAAAAACU=']]]]]], [[u'AAAAAAAAAAE=', [[u'AAAAAAAAABU=', [[ u'AAAAAAAAACU=']]]]]])
Module TreeDisplay.TreeTag, line 490, in tpRenderTABLE
- __traceback_info__: ([u'AAAAAAAAABU=', [[u'AAAAAAAAACU=']]], {'url': 'tpURL', 'nowrap': '1', 'branches': 'tpValues', 'id': 'tpId', 'childless_decoration': ''}, [[u'AAAAAAAAAAE=', [[u'AAAAAAAAABU=', [[u'AAAAAAAAACU=']]]]]], [[u'AAAAAAAAABU=', [[u'AAAAAAAAACU=']]]])
Module TreeDisplay.TreeTag, line 286, in tpRenderTABLE
Module OFS.ObjectManager, line 560, in tpValues
Module dm.zope.saml2.entity, line 134, in objectIds
Module dm.zope.saml2.authority, line 92, in id
Module zope.component._api, line 169, in getUtility
ComponentLookupError: (<InterfaceClass dm.zope.saml2.interfaces.ISamlAuthority>, '')
I don't understand what it is trying to do
This likely is a combined weakness of the TreeDisplay and the authority implementation.
An SAML authority object is a container for SAML entities. One of those entities corresponds to the authority itself (the others describe partners). This entity has the authority's id as id; it is not stored but accessed as a computed attribute. The error happens because the computation fails. The computation fails because TreeDisplay does not enter the Plone portal context, where the authority is registered.
Unfortunately, this breaks the top level manage. You can use instead manage_main at the top level or manage at the level of your Plone portal (then TreeDisplay works in the context your your Plone portal and will therefore succeed).
It should not be necessary to use such a workaround, but I will not be able to fix this issue before some weeks (for reasons of holidays).
Hi @djay
It was quite a while ago 
IIRC these were just cloned repos to be able to easily version the code. There were no significant changes as original packages got updated by @dieter to the version that was working for us.
The real problem were missing bindings in collective.saml2 and these were provided here https://github.com/collective/collective.saml2/tree/adfs_bindings Maybe they should be merged?
I hope it helped.
Cheers,
Pawel
@lewy awesome. that makes it even easier. I've created a PR and will update the docs and make a release
https://github.com/collective/collective.saml2/pull/5.
So with this it just works? Do you remember if there is any other special steps you need to make it talk to ADFS? Does ADFS support metadata urls?
IIRC you need to make sure the ordering of PAS plugins is correct. And yes, metadata is supported.
@lewy Is this new profile a superset of the old profile? ie is it likely to also work with all other SAML2 services that dm.saml2 already works with? if so, should I be trying to get @dieter to merge it instead?
If not, I'll have to find a way to make it selectable in the sitesetup.
Hi,
I'm sorry but I don't remember and I have no access to the old setup. I guess the best answers you'll get testing setup against real ADFS.