From trscavo at gmail.com  Mon Jul  2 07:22:04 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Mon, 2 Jul 2018 07:22:04 -0400
Subject: metadata filter doc summary
Message-ID: <CAEtu=dPvJY3itiDwo_6tU1BCP+wLcSuFOi3qgEBpV3m9zxo4ew@mail.gmail.com>

This message merely documents some changes made recently to the
metadata filter documentation. I don't think there is anything
earth-shattering here but all comments are welcome as always.

PS. Can someone please remove the comments on [2]? I don?t have access.

Thanks. Tom

-----
EntityRoleWhiteList metadata filter [1]
- Added warning re no child elements
- Added warning re affiliation descriptor
- Preserve affiliation descriptors in entity metadata [IDP-1310]

Predicate metadata filter [2]
- Added numerous new examples
- Added warning re no child elements
- Flip the default value of the removeEmptyEntitiesDescriptors
attribute [IDP-1307]

[1] EntityRoleWhiteListFilter https://wiki.shibboleth.net/confluence/x/_gInAQ

[2] PredicateMetadataFilter https://wiki.shibboleth.net/confluence/x/aAAzAQ

[IDP-1310] https://issues.shibboleth.net/jira/browse/IDP-1310

[IDP-1307] https://issues.shibboleth.net/jira/browse/IDP-1307

From trscavo at gmail.com  Tue Jul  3 13:35:45 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Tue, 3 Jul 2018 13:35:45 -0400
Subject: injecting a custom bean into a metadata filter
Message-ID: <CAEtu=dNKGrUOsAR3qqDf-mH3vU6t8hJb+LRcZELVkJY8iKDgHg@mail.gmail.com>

For Rod mainly---

I have two questions about the regex example you added to the
Predicate [1] metadata filter topic:

<bean id="the.Metadata.regexp.Pred"
class="net.shibboleth.utilities.java.support.logic.RegexPredicate"
c:_0="^.*sp1.*" />
<bean id="the.Metadata.Pred"
class="net.shibboleth.ext.spring.util.SpringExpressionPredicate"
        p:customObject-ref="the.Metadata.regexp.Pred"
        c:expression="#custom.apply(#input.getEntityID())" />

1. Where should I put the beans? Inside a metadata provider like any
other metadata filter?

2. Assuming the answer to the previous question is yes, why not
replace the second bean with

<MetadataFilter xsi:type="Predicate" direction="include"
removeEmptyEntitiesDescriptors="true">
    <ConditionScript customObjectRef="the.Metadata.regexp.Pred">
        <Script>
        <![CDATA[
            custom.apply(input.getEntityID());
        ]]>
        </Script>
    </ConditionScript>
</MetadataFilter>

Thanks,

Tom

[1] Predicate https://wiki.shibboleth.net/confluence/x/aAAzAQ

From rdw at steadingsoftware.com  Wed Jul  4 05:42:58 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Wed, 4 Jul 2018 10:42:58 +0100
Subject: injecting a custom bean into a metadata filter
In-Reply-To: <CAEtu=dNKGrUOsAR3qqDf-mH3vU6t8hJb+LRcZELVkJY8iKDgHg@mail.gmail.com>
References: <CAEtu=dNKGrUOsAR3qqDf-mH3vU6t8hJb+LRcZELVkJY8iKDgHg@mail.gmail.com>
Message-ID: <002e01d4137b$64b95640$2e2c02c0$@steadingsoftware.com>

> 1. Where should I put the beans? Inside a metadata provider like any
> other metadata filter?

Wherever suits you which out it into scope of the relevant Context.  I would put them in a file which was pointed to by
shibboleth.MetadataResolverResources  (which I think is what you mean when you say "Inside a metadata provider") since that way you
get reloadabilty of the important bit - see below for more about this.

 
> 2. Assuming the answer to the previous question is yes, why not
> replace the second bean with

[snip].  Many reasons, none of which have any importance to what is a "personal style" thing.

- A desire to see more documentation of the (phenomenally useful) SpringExpressionPredicate
- It's shorter
- A growing (and recent) disillusion with Oracle's inability to present a coherent story about JavaScript and hence a subliminal
desire to de-emphasise it.
- Because it was the way it happened.

As I say none of these reasons are really important.  Someone asked me to document how to do a regexp SP filter and so I just pulled
something (several somethings) together.  In the end it was for naught since its all 3.4 anyway and so a chocolate teapot for
someone who needs something for a current release.

To my mind, the real issue with either of these examples is the "functional inversion".  The thing that matters is the regexp, not
the injected predicate and that is not a natural way of reading that code.  Indeed I suppose I could say that putting what is
effectively function-free boiler plate into the custom syntax file, the JavaScript version draws attention away from the important
bit.  Someone says "Fix this _now_" to you and you don't want to waste time scanning MetadataResolver.xml to work what is happening,
you want to be end up at the bean file ASAP.   Maybe.

I should say that I am actively trying to work out a way to avoid this "functional inversion" in V3.4, but not really coming up with
any ideas.

R


From trscavo at gmail.com  Wed Jul  4 07:47:50 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Wed, 4 Jul 2018 07:47:50 -0400
Subject: injecting a custom bean into a metadata filter
In-Reply-To: <002e01d4137b$64b95640$2e2c02c0$@steadingsoftware.com>
References: <CAEtu=dNKGrUOsAR3qqDf-mH3vU6t8hJb+LRcZELVkJY8iKDgHg@mail.gmail.com>
 <002e01d4137b$64b95640$2e2c02c0$@steadingsoftware.com>
Message-ID: <CAEtu=dNGzL_W20X54ZC3bi8dq9SwrNu1oef_Lnr+0O7VGE1x1A@mail.gmail.com>

On Wed, Jul 4, 2018 at 5:42 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
>> 1. Where should I put the beans? Inside a metadata provider like any
>> other metadata filter?
>
> Wherever suits you which out it into scope of the relevant Context.

Hmm, I'm still missing something I'm afraid.

> I would put them in a file which was pointed to by
> shibboleth.MetadataResolverResources  (which I think is what you mean when you say "Inside a metadata provider")

Every sample filter on that page is assumed to be a child element of
some parent <MetadataProvider>. (A <MetadataFilter> outside of that
context is like a fish out of water.) I'm trying to understand how the
beans are associated with a particular metadata provider.

Thanks,

Tom

From rdw at steadingsoftware.com  Wed Jul  4 08:18:49 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Wed, 4 Jul 2018 13:18:49 +0100
Subject: injecting a custom bean into a metadata filter
In-Reply-To: <CAEtu=dNGzL_W20X54ZC3bi8dq9SwrNu1oef_Lnr+0O7VGE1x1A@mail.gmail.com>
References: <CAEtu=dNKGrUOsAR3qqDf-mH3vU6t8hJb+LRcZELVkJY8iKDgHg@mail.gmail.com>
 <002e01d4137b$64b95640$2e2c02c0$@steadingsoftware.com>
 <CAEtu=dNGzL_W20X54ZC3bi8dq9SwrNu1oef_Lnr+0O7VGE1x1A@mail.gmail.com>
Message-ID: <007a01d41391$2ab04dd0$8010e970$@steadingsoftware.com>

TL;DR - bung it in a separate file and point services.xml at it, just as you would any other native syntax.

> Hmm, I'm still missing something I'm afraid.

We do not allow custom syntax to be mixed with native syntax in V3.   There are several places where both native and custom syntax
have to be intermixed (eg[1]) and in support of that you can put the native syntax beans in several places[1].  Global.xml is an
obvious one but that suffers from lack of reloadability, so it would be more usual to bung it into a separate file [2] and point at
it from services.xml[3],[4].

You might want to skim over [5] again

[1] https://wiki.shibboleth.net/confluence/display/IDP30/PredicateConfiguration
[2] https://wiki.shibboleth.net/confluence/display/IDP30/SpringConfiguration
[3] https://wiki.shibboleth.net/confluence/display/IDP30/ReloadableServices
[4]
http://git.shibboleth.net/view/?p=java-identity-provider.git;a=blob;f=idp-conf/src/main/resources/conf/services.xml;h=e04ac8f0afceb2
d3afec9f0acbf2ed6c02a81a2c;hb=HEAD
[5] https://wiki.shibboleth.net/confluence/display/IDP30/Configuration#Configuration-ConfigurationOverviewsandReferences


From ian at iay.org.uk  Thu Jul  5 09:12:27 2018
From: ian at iay.org.uk (Ian Young)
Date: Thu, 5 Jul 2018 14:12:27 +0100
Subject: Shibboleth developer call 2018-07-06
Message-ID: <87D855A5-2AAA-462B-BF30-E8BE5B36C1BC@iay.org.uk>

The next Shibboleth developer call will take place tomorrow 2018-07-06 at the usual time:

Start Time:  10:00 Central US / 11:00 Eastern US / 16:00 UK
End Time:    12:00 Central US / 13:00 Eastern US / 18:00 UK

Access details can be found at

   https://wiki.shibboleth.net/confluence/display/DEV/ZoomGU

Agenda page is here:

   https://wiki.shibboleth.net/confluence/display/DEV/2018-07-06

See you there,

   -- Ian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20180705/0fb27e87/attachment.p7s>

From cantor.2 at osu.edu  Thu Jul  5 21:05:20 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Fri, 6 Jul 2018 01:05:20 +0000
Subject: SP release next week
Message-ID: <BF6E71C5-F017-431B-8C89-757FA0C19200@osu.edu>

Unless something unexpected pops up, I'd expect the release next Tuesday into Wednesday. I'll just have to improve the docs as I have time, they're probably 40% worked over.

-- Scott
?


From tdoan at smu.edu  Fri Jul  6 17:31:24 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Fri, 6 Jul 2018 21:31:24 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
Message-ID: <df1cd59d051e4e51b90c908ede07e799@smu.edu>

The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

A few other comments, and I'm still going through my initial experience with it. 

not immediately clear what the installation checkbox "Configure IIS7 modules" is for
 - appears to be for configuring the module to work with IIS
 - assumption is that without being checked, the module is installed but not "enabled" for IIS
 - shouldn't this be enabled by default? that is the case for the ISAPI modules with the v2 installer
if the installer is run again after an existing installation, 
 - the Change button does nothing
 - the Repair and Remove buttons do what you'd expect
the installer publisher (signing certificate) is unknown, which is also the case with the v2 installer
 - no functional problem, just the warning

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Rod Widdowson
Sent: Friday, June 29, 2018 10:55 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject: RE: SP v3 prerelease (windows)

>  > the service is still called Shibboleth 2 Daemon (default) . would be
> > nice if the upgrade renamed that to
> > Shibboleth 3 Daemon. (cosmetic yes but annoying)
> 
> Onto it.

Turns out I made this change a couple of days after we did the first beta...

-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Fri Jul  6 21:51:55 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Sat, 7 Jul 2018 01:51:55 +0000
Subject: SP RCs are up
Message-ID: <BYAPR01MB37025BC467432BFB015C5937D0460@BYAPR01MB3702.prod.exchangelabs.com>

Release candidates for the Windows [1] and Linux [2] packages for the 3.0 release are posted and these are probably the final ones (a typo isn't likely to matter, put it that way).

There are some older/unsupported RPM repos purged due to build failures, RH5 notably, but CentOS 5 still builds and should work there. SLE_10 is also gone.

xml-secuity-c-2.0.0 was tagged a couple of weeks ago and I tagged and uploaded log4shib 2.0.0 source this afternoon. The rest will be done at the release.

-- Scott

[1] http://shibboleth.net/downloads/prerelease/
[2] https://download.opensuse.org/repositories/home:/Scott_Cantor/


From takeshi at nii.ac.jp  Sat Jul  7 03:58:40 2018
From: takeshi at nii.ac.jp (Takeshi NISHIMURA)
Date: Sat, 7 Jul 2018 16:58:40 +0900
Subject: SP RCs are up
In-Reply-To: <BYAPR01MB37025BC467432BFB015C5937D0460@BYAPR01MB3702.prod.exchangelabs.com>
References: <BYAPR01MB37025BC467432BFB015C5937D0460@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <FBFCC9A3-406C-4438-8F33-8332B9758785@nii.ac.jp>

> 2018/07/07 10:51, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> [2] https://download.opensuse.org/repositories/home:/Scott_Cantor/

I didn't notice but it seems that the PGP key fingerprint is:

Importing GPG key 0x8DDA2C7D:
 Userid     : "home:Scott_Cantor OBS Project <home:Scott_Cantor at build.opensuse.org>"
 Fingerprint: 7139 7d89 d2f6 cb06 5bdb 2b96 b150 ccde 8dda 2c7d

Best regards,
Takeshi

From cantor.2 at osu.edu  Sat Jul  7 18:51:34 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Sat, 7 Jul 2018 22:51:34 +0000
Subject: SP RCs are up
In-Reply-To: <FBFCC9A3-406C-4438-8F33-8332B9758785@nii.ac.jp>
References: <BYAPR01MB37025BC467432BFB015C5937D0460@BYAPR01MB3702.prod.exchangelabs.com>
 <FBFCC9A3-406C-4438-8F33-8332B9758785@nii.ac.jp>
Message-ID: <BYAPR01MB370278DF2B0F6C517FD8A8B6D0460@BYAPR01MB3702.prod.exchangelabs.com>

> I didn't notice but it seems that the PGP key fingerprint is:
> 
> Importing GPG key 0x8DDA2C7D:
>  Userid     : "home:Scott_Cantor OBS Project
> <home:Scott_Cantor at build.opensuse.org>"
>  Fingerprint: 7139 7d89 d2f6 cb06 5bdb 2b96 b150 ccde 8dda 2c7d

All the RPMs are signed by the OBS, I take no responsibility for any of those keys. I won't resign the packages myself because I don't control the build. I only sign what I can personally vouch for.

-- Scott


From rdw at steadingsoftware.com  Sun Jul  8 07:40:47 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Sun, 8 Jul 2018 12:40:47 +0100
Subject: SP v3 prerelease (windows)
In-Reply-To: <df1cd59d051e4e51b90c908ede07e799@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
Message-ID: <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>

Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7 modules" is for
>  - assumption is that without being checked, the module is installed but not "enabled" for IIS

That?s absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

	appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
	appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the ISAPI modules with the v2 installer
> if the installer is run again after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the
IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I
can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to
configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for
open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer
code signed...

Thanks again for the feedback

Rod


From tdoan at smu.edu  Sun Jul  8 09:19:42 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Sun, 8 Jul 2018 13:19:42 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
Message-ID: <dd38a3df530c49f6834bc39db3809d76@smu.edu>

Sorry I omitted the detail but my testing is being done on a new Server 2016 OS and as the initial IIS and Shib SP installation, not as an upgrade. I had downloaded the SP installer on Friday morning but I see now it's since been updated so I'll use the latest and go through my testing again. More to come later this week. 

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Rod Widdowson
Sent: Sunday, July 8, 2018 6:41 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject: RE: SP v3 prerelease (windows)

Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7 
> modules" is for
>  - assumption is that without being checked, the module is installed 
> but not "enabled" for IIS

That's absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

	appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
	appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the 
> ISAPI modules with the v2 installer if the installer is run again 
> after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is 
> also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer code signed...

Thanks again for the feedback

Rod

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cbernardini at barracuda.com  Mon Jul  9 07:08:24 2018
From: cbernardini at barracuda.com (=?iso-8859-1?Q?C=E9sar_Bernardini?=)
Date: Mon, 9 Jul 2018 11:08:24 +0000
Subject: Unittest testXMLWithBlacklists
Message-ID: <1531134504503.56453@barracuda.com>

Hi,


I was running the OpenSAML 2.6.1's samltest-unittest-binary and I found that one of the unittests is failing: testXMLWithBlacklists.


It seems that the test requires the file (samltest/data/saml2/metadata/InCommon-metadata.xml) that contains the following information:


<!-- To run tests, download from http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml -->


The download URL is not available (at least from my domain). How can I retrieve this XML data?


Another test is trying to access (http://URL.TO.EXAMPLE/ORG/InCommon-metadata.xml). Do I need to register a special host name for URL.TO.EXAMPLE in order to make it work?


Thanks in advance,

________________________________
Barracuda Networks AG
Vorsitzender des Aufsichtsrates/ Chairman of the supervisory board: Dr. Klaus Perktold
Vorstand/ Executive Board: Dr. Klaus Gheri, Mag. Guenter Klausner
Sitz der Gesellschaft/ Registered office: 6020 Innsbruck, Austria
Handelsgericht Innsbruck Firmenbuch/ Registration Number: 184392s
UID-Nr/ VAT Number: ATU47509003

Zweigniederlassung Deutschland/ Office Germany: Radlkoferstr. 2, 81373 M?nchen
Handelsregister M?nchen / Registration Number: HRB 171749
UID-Nr/ VAT Number: DE237607533

===========================================================
Learn how to protect users, data, and applications with security engineered for the public cloud by Barracuda. http://barracuda.com

DISCLAIMER:
This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
===========================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20180709/5b147662/attachment.html>

From trscavo at gmail.com  Mon Jul  9 08:30:36 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Mon, 9 Jul 2018 08:30:36 -0400
Subject: Unittest testXMLWithBlacklists
In-Reply-To: <1531134504503.56453@barracuda.com>
References: <1531134504503.56453@barracuda.com>
Message-ID: <CAEtu=dP7jTWkDKVGRZ55wOdHVT4Gor3RfaE1MijMrF7mL908-Q@mail.gmail.com>

On Mon, Jul 9, 2018 at 7:08 AM, C?sar Bernardini
<cbernardini at barracuda.com> wrote:
>
> I was running the OpenSAML 2.6.1's samltest-unittest-binary and I found that
> one of the unittests is failing: testXMLWithBlacklists.
>
> It seems that the test requires the file
> (samltest/data/saml2/metadata/InCommon-metadata.xml) that contains the
> following information:
>
> <!-- To run tests, download from
> http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml -->
>
> The download URL is not available (at least from my domain). How can I
> retrieve this XML data?

The correct location is:

http://md.incommon.org/InCommon/InCommon-metadata.xml

You should probably file an issue to have that changed.

> Another test is trying to access
> (http://URL.TO.EXAMPLE/ORG/InCommon-metadata.xml). Do I need to register a
> special host name for URL.TO.EXAMPLE in order to make it work?

No, I doubt it. Maybe someone else can provide further instructions.

HTH,

Tom

From cantor.2 at osu.edu  Mon Jul  9 09:05:07 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Mon, 9 Jul 2018 13:05:07 +0000
Subject: Unittest testXMLWithBlacklists
In-Reply-To: <1531134504503.56453@barracuda.com>
References: <1531134504503.56453@barracuda.com>
Message-ID: <BYAPR01MB3702FC9D8365D182C2051ADCD0440@BYAPR01MB3702.prod.exchangelabs.com>

> I was running the OpenSAML 2.6.1's samltest-unittest-binary and I found that
> one of the unittests is failing: testXMLWithBlacklists.

The tests are for internal use only.

-- Scott


From rdw at steadingsoftware.com  Mon Jul  9 09:21:20 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Mon, 9 Jul 2018 14:21:20 +0100
Subject: Unittest testXMLWithBlacklists
In-Reply-To: <BYAPR01MB3702FC9D8365D182C2051ADCD0440@BYAPR01MB3702.prod.exchangelabs.com>
References: <1531134504503.56453@barracuda.com>
 <BYAPR01MB3702FC9D8365D182C2051ADCD0440@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <00bc01d41787$ba76f910$2f64eb30$@steadingsoftware.com>

> > I was running the OpenSAML 2.6.1's samltest-unittest-binary and I found that
> > one of the unittests is failing: testXMLWithBlacklists.
> 
> The tests are for internal use only.

Also 2.6.1 dates from December 2013.  It is totally out of date and it and its dependants will be subject to multiple security
advisories.


From tdoan at smu.edu  Mon Jul  9 18:01:13 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Mon, 9 Jul 2018 22:01:13 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <dd38a3df530c49f6834bc39db3809d76@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
Message-ID: <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>

Just passing along feedback as I gain some experience with the new SP. 

Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove the iis7_shib.dll modules (ShibNative and ShibNative32). This prevents IIS from starting until the modules are manually removed. I had to remove the DLL from the Modules component at both the server and site level, and also modify applicationHost.config to remove these lines from the globalModules element. 

            <add name="ShibNative32" image="C:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" preCondition="bitness32" />
            <add name="ShibNative" image="C:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" preCondition="bitness64" />

-----Original Message-----
From: Doan, Tommy 
Sent: Sunday, July 8, 2018 8:20 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject: RE: SP v3 prerelease (windows)

Sorry I omitted the detail but my testing is being done on a new Server 2016 OS and as the initial IIS and Shib SP installation, not as an upgrade. I had downloaded the SP installer on Friday morning but I see now it's since been updated so I'll use the latest and go through my testing again. More to come later this week. 

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Rod Widdowson
Sent: Sunday, July 8, 2018 6:41 AM
To: 'Shib Dev' <dev at shibboleth.net>
Subject: RE: SP v3 prerelease (windows)

Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7 
> modules" is for
>  - assumption is that without being checked, the module is installed 
> but not "enabled" for IIS

That's absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

	appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
	appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the 
> ISAPI modules with the v2 installer if the installer is run again 
> after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is 
> also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer code signed...

Thanks again for the feedback

Rod

--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Mon Jul  9 19:27:48 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Mon, 9 Jul 2018 23:27:48 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
Message-ID: <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>

> Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove
> the iis7_shib.dll modules (ShibNative and ShibNative32). 

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.

-- Scott



From cantor.2 at osu.edu  Mon Jul  9 19:39:12 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Mon, 9 Jul 2018 23:39:12 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
Message-ID: <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>

Same result running Installer -> Remove.

Note that I don't think it would, and I wouldn't want it to, do that step if you didn't auto-configure the module during install, those are intended to be paired. Auto -> Auto, or Manual -> Manual.

-- Scott

On 7/9/18, 7:30 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

> Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove
> the iis7_shib.dll modules (ShibNative and ShibNative32). 

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.



From tdoan at smu.edu  Mon Jul  9 19:56:56 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Mon, 9 Jul 2018 23:56:56 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
Message-ID: <226b53b860d64cbaa366adcf80ca40b8@smu.edu>

Agreed, and I had the "Configure IIS7 modules" checkbox enabled when I originally installed the SP software. 

I just went through the Remove procedure again and confirmed the modules are not removed from IIS. I'm using the installer just downloaded today since I notice the file date had changed. To be clear, the DLLs are removed from the file system but not from the IIS configuration and not from C:\Windows\System32\inetsrv\config\applicationHost.config. 

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 6:39 PM
To: Shib Dev <dev at shibboleth.net>
Subject: Re: SP v3 prerelease (windows)

Same result running Installer -> Remove.

Note that I don't think it would, and I wouldn't want it to, do that step if you didn't auto-configure the module during install, those are intended to be paired. Auto -> Auto, or Manual -> Manual.

-- Scott

On 7/9/18, 7:30 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

> Uninstalling the v3 software, at least by running the installer again 
> and choosing the Remove option, does not remove the iis7_shib.dll modules (ShibNative and ShibNative32).

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.


--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Mon Jul  9 20:04:30 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 00:04:30 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
Message-ID: <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>

On 7/9/18, 7:57 PM, "dev on behalf of Doan, Tommy" <dev-bounces at shibboleth.net on behalf of tdoan at smu.edu> wrote:

> I just went through the Remove procedure again and confirmed the modules are not removed from IIS.

On my test VM they definitely are, so that basically leaves it at "Windows is broken, news at 11."

You should still be able to use the appcmd.exe approach to "unregister" the module, I would think, there shouldn't be any need to manually do it (in the sense of using the GUI). Actually, if it doesn't, that basically *is* the problem, since that's what the installer actually does at uninstall. It can't make that work if the commands just refuse to do what they're supposed to, it doesn't directly touch the config.

-- Scott



From tdoan at smu.edu  Mon Jul  9 20:42:01 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Tue, 10 Jul 2018 00:42:01 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
Message-ID: <be5fe05029f44121b81de1c9cb587769@smu.edu>

Probably functionally minor but environment variable SHIBSP_PREFIX should be set to C:\opt\shibboleth-sp rather than C:/opt/shibboleth-sp.

One other comment. This tripped me up for quite a while until I did a file compare to the dist version of shibboleth2.xml and then noticed the documentation. 
https://wiki.shibboleth.net/confluence/display/SP3/FolderMetadataProvider 

        <MetadataProvider type="XML" validate="true" path="idp-metadata.xml"/>

Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml. 

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 7:05 PM
To: Shib Dev <dev at shibboleth.net>
Subject: Re: SP v3 prerelease (windows)

On 7/9/18, 7:57 PM, "dev on behalf of Doan, Tommy" <dev-bounces at shibboleth.net on behalf of tdoan at smu.edu> wrote:

> I just went through the Remove procedure again and confirmed the modules are not removed from IIS.

On my test VM they definitely are, so that basically leaves it at "Windows is broken, news at 11."

You should still be able to use the appcmd.exe approach to "unregister" the module, I would think, there shouldn't be any need to manually do it (in the sense of using the GUI). Actually, if it doesn't, that basically *is* the problem, since that's what the installer actually does at uninstall. It can't make that work if the commands just refuse to do what they're supposed to, it doesn't directly touch the config.

-- Scott


-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Mon Jul  9 20:49:47 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 00:49:47 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <be5fe05029f44121b81de1c9cb587769@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
Message-ID: <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>

On 7/9/18, 8:42 PM, "dev on behalf of Doan, Tommy" <dev-bounces at shibboleth.net on behalf of tdoan at smu.edu> wrote:

> Probably functionally minor but environment variable SHIBSP_PREFIX should be set to C:\opt\shibboleth-sp rather than > C:/opt/shibboleth-sp.

The code all depends on and assumes portable paths. Forward slash works in the parser, so that's what it uses. Sometimes backslash will work and sometimes it does not, and it should never be used.
 
> Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -
> check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml. 

"file" works in a legacy config and it warns. It will not work in a V3 config. The package doesn't supply any configuration of that plugin and I believe all the examples are fixed to use the proper syntax.

But I don't think there are any examples shipped before or now of the Folder plugin (it shouldn't be used anymore anyway but that's beside the point).

If you're seeing broken example it's probably a bug I already know about and only affects upgrades, it's not going to hold the release. It's not getting all the files in dist/ updated correctly. But I don't know where this one would be coming from.

-- Scott



From cantor.2 at osu.edu  Mon Jul  9 20:58:10 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 00:58:10 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
Message-ID: <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>

On 7/9/18, 8:52 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

> > Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -
> > check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml. 

I misread you, the Folder reference confused me.

If you use this:

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

That works fine in an upgraded system, and there will a DEPRECATED warning in the log telling you exactly what it found and what to do with it. And if you bump the namespace without fixing it first, yes, it breaks (and it should say why there also). If you see any DEPRECATEDs in the log, you are going to break it if you just change the namespace, with the exception of the warnings that are actually noting it's using the old namespace.

The deprecation warnings are, by and large, extremely specific.

-- Scott



From rdw at steadingsoftware.com  Tue Jul 10 05:17:02 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Tue, 10 Jul 2018 10:17:02 +0100
Subject: @since annotation
Message-ID: <00c901d4182e$c39aeea0$4ad0cbe0$@steadingsoftware.com>

Can I just check that if we use @since in a subproject then the version is the one of the project (not of the IdP).

So if something is new in spring-support and will first see the light of day in IdP 3.4.0 the @since in 5.4.0 (likewise 7.4.0 for
java-support).

I don't want to go in and change things which were not accidental numbering.


From cantor.2 at osu.edu  Tue Jul 10 08:20:17 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 12:20:17 +0000
Subject: @since annotation
In-Reply-To: <00c901d4182e$c39aeea0$4ad0cbe0$@steadingsoftware.com>
References: <00c901d4182e$c39aeea0$4ad0cbe0$@steadingsoftware.com>
Message-ID: <BYAPR01MB370220F77CADD673C53610CBD05B0@BYAPR01MB3702.prod.exchangelabs.com>

> So if something is new in spring-support and will first see the light of day in
> IdP 3.4.0 the @since in 5.4.0 (likewise 7.4.0 for java-support).

Yes, it's the library version of the javadoc itself.

-- Scott


From tdoan at smu.edu  Tue Jul 10 09:56:58 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Tue, 10 Jul 2018 13:56:58 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
 <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
Message-ID: <58e30e52708a454bb9471150b4247a99@smu.edu>

I'm testing with a fresh v3 installation, but my shibboleth2.xml was largely built from an existing v2 file where the file attribute of the MetadataProvider element is used, so this isn't coming from any documentation I've seen - at least not for many years. By the way, nothing is logged in any SP log when this causes a crash, but the following Event ID 1000 does appear in the Event Viewer's Application log although not very helpful. 

Faulting application name: shibd.exe, version: 3.0.0.0, time stamp: 0x5b400ce7
Faulting module name: xmltooling3_0.dll, version: 3.0.0.0, time stamp: 0x5b4007d4
Exception code: 0xc0000005
Fault offset: 0x00042667
Faulting process id: 0x1010
Faulting application start time: 0x01d417e3efc6f310
Faulting application path: C:\opt\shibboleth-sp\sbin\shibd.exe
Faulting module path: C:\Program Files (x86)\Shibboleth\SP\lib\xmltooling3_0.dll
Report Id: c201d960-e372-45c8-b07d-8b64c3333f0b
Faulting package full name: 
Faulting package-relative application ID:

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 7:58 PM
To: Shib Dev <dev at shibboleth.net>
Subject: Re: SP v3 prerelease (windows)

On 7/9/18, 8:52 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

> > Versus the v2 'file' attribute which is now a breaking configuration 
> > that prevents the service from starting or shibd - check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml.

I misread you, the Folder reference confused me.

If you use this:

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

That works fine in an upgraded system, and there will a DEPRECATED warning in the log telling you exactly what it found and what to do with it. And if you bump the namespace without fixing it first, yes, it breaks (and it should say why there also). If you see any DEPRECATEDs in the log, you are going to break it if you just change the namespace, with the exception of the warnings that are actually noting it's using the old namespace.

The deprecation warnings are, by and large, extremely specific.

-- Scott


--
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Tue Jul 10 10:23:55 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 14:23:55 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <58e30e52708a454bb9471150b4247a99@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
 <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
 <58e30e52708a454bb9471150b4247a99@smu.edu>
Message-ID: <BYAPR01MB3702D341719FF9938BD989B0D05B0@BYAPR01MB3702.prod.exchangelabs.com>

> I'm testing with a fresh v3 installation, but my shibboleth2.xml was largely
> built from an existing v2 file where the file attribute of the MetadataProvider
> element is used, so this isn't coming from any documentation I've seen - at
> least not for many years. By the way, nothing is logged in any SP log when
> this causes a crash, but the following Event ID 1000 does appear in the Event
> Viewer's Application log although not very helpful.

You don't have to file a bug if you can't for some reason, but I can't research something without the configuration to reproduce it.

-- Scott


From cantor.2 at osu.edu  Tue Jul 10 10:28:34 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 14:28:34 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <BYAPR01MB3702D341719FF9938BD989B0D05B0@BYAPR01MB3702.prod.exchangelabs.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
 <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
 <58e30e52708a454bb9471150b4247a99@smu.edu>
 <BYAPR01MB3702D341719FF9938BD989B0D05B0@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <BYAPR01MB3702F48BD1EAD0F63DF0C243D05B0@BYAPR01MB3702.prod.exchangelabs.com>

> You don't have to file a bug if you can't for some reason, but I can't research
> something without the configuration to reproduce it.

(If you're saying that particular kind of unsupported metadata syntax causes a crash, I need a specific example, nothing I have tested has ever done that, it's a handled error.)

-- Scott


From cantor.2 at osu.edu  Tue Jul 10 13:33:09 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 17:33:09 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <BYAPR01MB3702F48BD1EAD0F63DF0C243D05B0@BYAPR01MB3702.prod.exchangelabs.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
 <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
 <58e30e52708a454bb9471150b4247a99@smu.edu>
 <BYAPR01MB3702D341719FF9938BD989B0D05B0@BYAPR01MB3702.prod.exchangelabs.com>
 <BYAPR01MB3702F48BD1EAD0F63DF0C243D05B0@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <BYAPR01MB37020C9154FBAA3D357218F7D05B0@BYAPR01MB3702.prod.exchangelabs.com>

> (If you're saying that particular kind of unsupported metadata syntax causes
> a crash, I need a specific example, nothing I have tested has ever done that,
> it's a handled error.)

Never mind, found a regression, thank you.

-- Scott


From cantor.2 at osu.edu  Tue Jul 10 14:27:03 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 10 Jul 2018 18:27:03 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <BYAPR01MB37020C9154FBAA3D357218F7D05B0@BYAPR01MB3702.prod.exchangelabs.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <28AE9919-526D-4123-9D6E-C535121DB4CE@osu.edu>
 <0FF39CB5-34A3-4693-95EB-23043AD7039C@osu.edu>
 <226b53b860d64cbaa366adcf80ca40b8@smu.edu>
 <36C92C32-C9A3-4190-A663-4609E247B7B3@osu.edu>
 <be5fe05029f44121b81de1c9cb587769@smu.edu>
 <5A48EE17-789A-4238-9774-3EDBBFEE801A@osu.edu>
 <A74C44AF-5EC0-4E9C-8838-CB316BEB83CB@osu.edu>
 <58e30e52708a454bb9471150b4247a99@smu.edu>
 <BYAPR01MB3702D341719FF9938BD989B0D05B0@BYAPR01MB3702.prod.exchangelabs.com>
 <BYAPR01MB3702F48BD1EAD0F63DF0C243D05B0@BYAPR01MB3702.prod.exchangelabs.com>
 <BYAPR01MB37020C9154FBAA3D357218F7D05B0@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <BYAPR01MB370217991B787A16159FF26ED05B0@BYAPR01MB3702.prod.exchangelabs.com>

Crash is fixed, I'll push a new package later today. Since people continue to test and find bugs I won't tag it tonight but tomorrow is still possible, probably more likely Thursday morning. I will start pushing the already tagged library RPMs out tonight.

-- Scott


From rdw at steadingsoftware.com  Wed Jul 11 06:01:34 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Wed, 11 Jul 2018 11:01:34 +0100
Subject: Documenting Predicates, Functions (and ActivationConditions)
Message-ID: <008201d418fe$270006e0$750014a0$@steadingsoftware.com>

We discusses this on Friday; it's all part of IDP-1314, but I'd like a slightly wider audience than just the comments section of
that case.

I have a desire, provoked (as was IDP-1314) from a Support case asking for a MetadataFilter on the RegExp of the EntityID, to
provide documentation for all the Functions and Predicates that are declared system\conf\utilities.xml.

As I started on this yesterday I (re) discovered the ActivationConditions[1] page, this is an awesome cookbook for on particular
flavour of what I want to get documented (Specifically Predicate<ProfileRequestContext>).

I rather badly do not want to disturb that page too much (it should be a bookmark for anyone doing complex deployments).  So my plan
(which I want to test with this audience) is to:

- Collapse ExternalAttributePluginActivationConditions [2] into ActivationConditions[1] (partially completed yesterday)

- Build a page under SpringConfiguration [3] documenting Functions and Predicates (probably move the words in preface to
ActivationConditions) making sure it is understood that this is the list of potential ingredients and, not the cook-book

- Under this, detail (probably in a table, but maybe a page per bean) each Predicate/Function featuring
   - Abstract Bean name (from utilities.xml)
   - Signature (Function/Predicate and input/output types)
   - Reference to the JavaDoc
   - An example
   - I also would like list the Constructor names, Factory names, property names.  This does duplicate the Javadoc but does keep
everything together..

This leave ActivationsConditions as a crib sheet for them and we have single goto list for all Functions and Predicates.  Obviously
each page would reference the other

Obviously the details plan will change as I actually do the writing, but I wanted to garner input before I start..

Rod

[1] https://wiki.shibboleth.net/confluence/display/IDP30/ActivationConditions
[2] https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAttributePluginActivationConditions
[3] https://wiki.shibboleth.net/confluence/display/IDP30/SpringConfiguration


From cantor.2 at osu.edu  Wed Jul 11 11:07:41 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Wed, 11 Jul 2018 15:07:41 +0000
Subject: SP release will be delayed into next week
Message-ID: <BYAPR01MB370218A6163ED3741D9BA971D05A0@BYAPR01MB3702.prod.exchangelabs.com>

A fairly significant bit of problem code was found as a side effect of a silly unrelated bug, so I'm going to need to do a little patching and don't want to rush it for no good reason. Please keep poking and testing particularly now that there's a little time for more work.

-- Scott


From tdoan at smu.edu  Wed Jul 11 11:19:27 2018
From: tdoan at smu.edu (Doan, Tommy)
Date: Wed, 11 Jul 2018 15:19:27 +0000
Subject: SP release will be delayed into next week
In-Reply-To: <BYAPR01MB370218A6163ED3741D9BA971D05A0@BYAPR01MB3702.prod.exchangelabs.com>
References: <BYAPR01MB370218A6163ED3741D9BA971D05A0@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <071a727619f846588df2d56c8e339155@smu.edu>

Maybe it goes without saying, but should I bother to use the most recent installer each time I get a chance to do some work on this? If so, should I upgrade in place or uninstall and reinstall? 

I'm working only with the Windows v3 prerelease and only on IIS from Server 2016. 

-----Original Message-----
From: dev <dev-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, July 11, 2018 10:08 AM
To: Shib Dev <dev at shibboleth.net>
Subject: SP release will be delayed into next week

A fairly significant bit of problem code was found as a side effect of a silly unrelated bug, so I'm going to need to do a little patching and don't want to rush it for no good reason. Please keep poking and testing particularly now that there's a little time for more work.

-- Scott

-- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net

From cantor.2 at osu.edu  Wed Jul 11 11:23:16 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Wed, 11 Jul 2018 15:23:16 +0000
Subject: SP release will be delayed into next week
In-Reply-To: <071a727619f846588df2d56c8e339155@smu.edu>
References: <BYAPR01MB370218A6163ED3741D9BA971D05A0@BYAPR01MB3702.prod.exchangelabs.com>
 <071a727619f846588df2d56c8e339155@smu.edu>
Message-ID: <BYAPR01MB3702834881F0A0D01452C9D9D05A0@BYAPR01MB3702.prod.exchangelabs.com>

> Maybe it goes without saying, but should I bother to use the most recent
> installer each time I get a chance to do some work on this? If so, should I
> upgrade in place or uninstall and reinstall?

Always uninstall completely, they won't work otherwise, it will just do nothing if it installs over top.

The next one I post will be labeled RC1 and at least one of the DLLs will be bumped and probably the installer will be 3.0.0.1 to make sure it's non-overlapping.

-- Scott


From trscavo at gmail.com  Wed Jul 11 11:51:50 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Wed, 11 Jul 2018 11:51:50 -0400
Subject: Documenting Predicates, Functions (and ActivationConditions)
In-Reply-To: <008201d418fe$270006e0$750014a0$@steadingsoftware.com>
References: <008201d418fe$270006e0$750014a0$@steadingsoftware.com>
Message-ID: <CAEtu=dPTiVvyCmDwaDd+jK98BTHLxagiQuLos9B49D1_RNjrPA@mail.gmail.com>

On Wed, Jul 11, 2018 at 6:01 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
>
> I rather badly do not want to disturb that page too much (it should be a bookmark for anyone doing complex deployments).

Made some minor edits. Rewrote the JavaScript for clarity. Revert if necessary.

Tom

From rdw at steadingsoftware.com  Thu Jul 12 07:13:06 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Thu, 12 Jul 2018 12:13:06 +0100
Subject: SP v3 prerelease (windows)
In-Reply-To: <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
Message-ID: <00f101d419d1$500c0010$f0240030$@steadingsoftware.com>

For completeness since this was talked to death

> Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove the
iis7_shib.dll
> modules (ShibNative and ShibNative32). 

I happened to be in the code for another reason and I see that we are indeed doing the uninstall, so you behvaior comes as a
"Windows is Odd"....

If this happens repeatably, I'd be interested in the logfile from  

	msiexec /x <misname> /lv* LOGFILE

(/x means uninstall)

Mail it to me direct (it will be big) and do NOT mail me a log from a production/sensitive machine.  Whilst I do not believe that
there is any confidential information in the log file but I am not prepared to take the risk and neither should you.

Rod


From cantor.2 at osu.edu  Thu Jul 12 09:27:25 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Thu, 12 Jul 2018 13:27:25 +0000
Subject: SP v3 prerelease (windows)
In-Reply-To: <00f101d419d1$500c0010$f0240030$@steadingsoftware.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <00f101d419d1$500c0010$f0240030$@steadingsoftware.com>
Message-ID: <BYAPR01MB3702EFEDD4C9878C8235B357D0590@BYAPR01MB3702.prod.exchangelabs.com>

> I happened to be in the code for another reason and I see that we are
> indeed doing the uninstall, so you behvaior comes as a "Windows is Odd"....
> 
> If this happens repeatably, I'd be interested in the logfile from
> 
> 	msiexec /x <misname> /lv* LOGFILE
> 
> (/x means uninstall)

I also think just running the appcmd to unregister the module from a shell would be useful. My suspicion is that isn't working, and that's probably why the installer couldn't undo it. If we had some notion of why, then it might be fixable but I don't imagine it would be a repeatable scenario and ultimately it can't do much if the command just won't work.

-- Scott


From rdw at steadingsoftware.com  Thu Jul 12 10:25:42 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Thu, 12 Jul 2018 15:25:42 +0100
Subject: SP v3 prerelease (windows)
In-Reply-To: <BYAPR01MB3702EFEDD4C9878C8235B357D0590@BYAPR01MB3702.prod.exchangelabs.com>
References: <CAObj+SXnxKZV7jhTAVdv2fe7ZkF-m6XtmyoJ=E3Lhiqd6xobNg@mail.gmail.com>
 <01c801d40fbf$39b488d0$ad1d9a70$@steadingsoftware.com>
 <01cc01d40fc1$940901b0$bc1b0510$@steadingsoftware.com>
 <df1cd59d051e4e51b90c908ede07e799@smu.edu>
 <008f01d416b0$83cb7030$8b625090$@steadingsoftware.com>
 <dd38a3df530c49f6834bc39db3809d76@smu.edu>
 <3bc6a19be0184001b4ca9a00b3ec7763@smu.edu>
 <00f101d419d1$500c0010$f0240030$@steadingsoftware.com>
 <BYAPR01MB3702EFEDD4C9878C8235B357D0590@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <014201d419ec$381e67c0$a85b3740$@steadingsoftware.com>

> I also think just running the appcmd to unregister the module from a shell would be useful. 

Which is (for the record)

C:\windows\System32\InetSrv\appcmd.exe uninstall module ShibNative32
C:\windows\System32\InetSrv\appcmd.exe uninstall module ShibNative




From trscavo at gmail.com  Thu Jul 12 14:33:07 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Thu, 12 Jul 2018 14:33:07 -0400
Subject: Documenting Predicates, Functions (and ActivationConditions)
In-Reply-To: <CAEtu=dPTiVvyCmDwaDd+jK98BTHLxagiQuLos9B49D1_RNjrPA@mail.gmail.com>
References: <008201d418fe$270006e0$750014a0$@steadingsoftware.com>
 <CAEtu=dPTiVvyCmDwaDd+jK98BTHLxagiQuLos9B49D1_RNjrPA@mail.gmail.com>
Message-ID: <CAEtu=dPpPjAZXXCOAwYyPB-6x0DFNm1-pdJ+a7z9wBxEzv9EDA@mail.gmail.com>

I don't know if it's relevant but the schema on HEAD defines

<element name="ActivationConditionScript" type="resolver:ScriptType"
minOccurs="0">

but it's not documented AFAICT.

Tom

From cantor.2 at osu.edu  Fri Jul 13 14:14:03 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Fri, 13 Jul 2018 18:14:03 +0000
Subject: Possible bug with DiscoFeed in SP3
In-Reply-To: <alpine.LFD.2.21.1807131834520.3004@austen3.home>
References: <alpine.LFD.2.21.1807131834520.3004@austen3.home>
Message-ID: <4EDAFDFB-5DA6-4A4B-AEC8-ADEB3A278D27@osu.edu>

Please don't use private email.

On 7/13/18, 2:01 PM, "Michael Young" <m.a.young at durham.ac.uk> wrote:

> Have I made a mistake somewhere (which is entirely possible not least 
> because I rebuilt most of the packages to get them working on my OS) or is 
> this a real bug?

I presume a mistake since shibboleth.net is in that state and discovery is working fine.
 
-- Scott



From trscavo at gmail.com  Sat Jul 14 11:27:29 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Sat, 14 Jul 2018 11:27:29 -0400
Subject: the semantics of AttributeFilterScript
Message-ID: <CAEtu=dNHh_qesiRfQDp0Y-nO_NcFyiC9vHcrR2AmSd+uiYP07Q@mail.gmail.com>

The documentation for the <AttributeFilterScript> element [1] is
contradictory. The description says one thing (remove if false) but
the example seems to be saying something else (remove if true). Which
is it?

The entity attribute is removed if the predicate evaluates to (true or false)?

Thanks,

Tom

[1] EntityAttributesFilter https://wiki.shibboleth.net/confluence/x/ZgMnAQ

From ian at iay.org.uk  Thu Jul 19 12:24:00 2018
From: ian at iay.org.uk (Ian Young)
Date: Thu, 19 Jul 2018 17:24:00 +0100
Subject: Shibboleth developer call 2018-07-20
Message-ID: <C6B1066A-D1F7-405C-B545-3731F95650F5@iay.org.uk>

The next Shibboleth developer call will take place tomorrow 2018-07-20 at the usual time:

Start Time:  10:00 Central US / 11:00 Eastern US / 16:00 UK
End Time:    12:00 Central US / 13:00 Eastern US / 18:00 UK

Access details can be found at

   https://wiki.shibboleth.net/confluence/display/DEV/ZoomGU

Agenda page is here:

   https://wiki.shibboleth.net/confluence/display/DEV/2018-07-20

See you there,

   -- Ian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20180719/550b3b2f/attachment.p7s>

From trscavo at gmail.com  Tue Jul 24 13:02:43 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Tue, 24 Jul 2018 13:02:43 -0400
Subject: ECMAScript target version
Message-ID: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>

Until recently I didn't know much about the various scripting engines
(Rhino, Nashorn, GraalVM, etc.) and how well they support the
ECMAScript standard. After doing some research on the subject, I've
concluded that the target version for sample scripts should be
ECMAScript 5.1, so I'll stick to that as best I can. This is rather
inconvenient since ECMAScript 2015 (aka ECMAScript 6) is near
universal AFAICT.

In any case, I documented suggested best coding practices in the
ScriptTypeConfiguration [1] topic. I tried to stay away from
contentious issues (involving [2], e.g.) but if you could review and
comment on what I wrote in the wiki, I'd appreciate it.

Thanks,

Tom

[1] ScriptTypeConfiguration  https://wiki.shibboleth.net/confluence/x/iQAOAg
[2] https://issues.shibboleth.net/jira/browse/JPAR-121

From rdw at steadingsoftware.com  Tue Jul 24 14:00:32 2018
From: rdw at steadingsoftware.com (Rod Widdowson)
Date: Tue, 24 Jul 2018 14:00:32 -0400
Subject: ECMAScript target version
In-Reply-To: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>
References: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>
Message-ID: <00a401d42378$37e7c1d0$a7b74570$@steadingsoftware.com>

My immediate reaction is that it is out of scope for us to be telling any of our customer how to write scripts, and in particular
what language they should use.

We should go for the lowest common denominator in our example (so if something will work in rhino and Nashorn that is what we should
ship).  Further I think that we need to have the simplest possible code in our examples.  So the extra levekl of function
indirection that a lot of the samples currently have is just confusing for people who are not programmers and must want to get a job
done.  So we might know that

(funcrtion(foo, custom, prc){return false;} (input, custom, prc);

Is the same as

false;

but it is far more interesting to our end users that they see the latter.

R

> -----Original Message-----
> From: dev [mailto:dev-bounces at shibboleth.net] On Behalf Of Tom Scavo
> Sent: 24 July 2018 13:03
> To: Shibboleth Developers <dev at shibboleth.net>
> Subject: ECMAScript target version
> 
> Until recently I didn't know much about the various scripting engines (Rhino, Nashorn, GraalVM, etc.) and how well they support
the
> ECMAScript standard. After doing some research on the subject, I've concluded that the target version for sample scripts should be
> ECMAScript 5.1, so I'll stick to that as best I can. This is rather inconvenient since ECMAScript 2015 (aka ECMAScript 6) is near
universal
> AFAICT.
> 
> In any case, I documented suggested best coding practices in the ScriptTypeConfiguration [1] topic. I tried to stay away from
> contentious issues (involving [2], e.g.) but if you could review and comment on what I wrote in the wiki, I'd appreciate it.
> 
> Thanks,
> 
> Tom
> 
> [1] ScriptTypeConfiguration  https://wiki.shibboleth.net/confluence/x/iQAOAg
> [2] https://issues.shibboleth.net/jira/browse/JPAR-121
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net


From cantor.2 at osu.edu  Tue Jul 24 14:06:09 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 24 Jul 2018 18:06:09 +0000
Subject: ECMAScript target version
In-Reply-To: <00a401d42378$37e7c1d0$a7b74570$@steadingsoftware.com>
References: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>
 <00a401d42378$37e7c1d0$a7b74570$@steadingsoftware.com>
Message-ID: <BYAPR01MB37024B66EC18C3238B09BAABD0550@BYAPR01MB3702.prod.exchangelabs.com>

> We should go for the lowest common denominator in our example (so if
> something will work in rhino and Nashorn that is what we should ship).

Unfortunately those two are fairly different in practice, so beyond simple examples it's common to have to pick one, and I've stuck with Nashorn since that is the official Java implementation now. And given that it will probably be 2021 at the earliest before that changes, it's not an urgent thing to deal with it changing, we just have to keep an eye out.

> Further I think that we need to have the simplest possible code in our
> examples.  So the extra levekl of function indirection that a lot of the samples
> currently have is just confusing for people who are not programmers and
> must want to get a job done.  So we might know that
> 
> (funcrtion(foo, custom, prc){return false;} (input, custom, prc);
> 
> Is the same as
> 
> false;
> 
> but it is far more interesting to our end users that they see the latter.

+1, these are, by and large, already just simple function calls, so that indirection doesn't really add anything useful unless the example is so advanced that there's a portion that needs to be factored. I don't mind an example or two showing it, but they shouldn't routinely.

-- Scott


From trscavo at gmail.com  Wed Jul 25 15:04:44 2018
From: trscavo at gmail.com (Tom Scavo)
Date: Wed, 25 Jul 2018 15:04:44 -0400
Subject: ECMAScript target version
In-Reply-To: <BYAPR01MB37024B66EC18C3238B09BAABD0550@BYAPR01MB3702.prod.exchangelabs.com>
References: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>
 <00a401d42378$37e7c1d0$a7b74570$@steadingsoftware.com>
 <BYAPR01MB37024B66EC18C3238B09BAABD0550@BYAPR01MB3702.prod.exchangelabs.com>
Message-ID: <CAEtu=dNaMFpVDPY-XHO7Kx_HOqPBxx370ksT-dhiQkKQLt3ECQ@mail.gmail.com>

Thanks for the feedback. That saves me a lot of time. For now, I?ll
just leave things as they are. Feel free to jump in and change the
docs to suit your taste.

That said, here?s my two cents. The function indirection has at least
three advantages: 1) it permits the use of the return statement; 2) it
introduces formal parameters with meaningful names; and 3) it aligns
with the definition of Guava Functions and Predicates.

Btw, Guava is mostly redundant at this point due to the introduction
of the java.util.function package in Java 8, but the two approaches
are similar in spirit, so I guess it doesn?t matter.

Tom

From cantor.2 at osu.edu  Wed Jul 25 16:50:45 2018
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Wed, 25 Jul 2018 20:50:45 +0000
Subject: ECMAScript target version
In-Reply-To: <CAEtu=dNaMFpVDPY-XHO7Kx_HOqPBxx370ksT-dhiQkKQLt3ECQ@mail.gmail.com>
References: <CAEtu=dPki6gGKrPSnrHmPBZMFXxc+n=RBTVEv+poFU=AD3R0mQ@mail.gmail.com>
 <00a401d42378$37e7c1d0$a7b74570$@steadingsoftware.com>
 <BYAPR01MB37024B66EC18C3238B09BAABD0550@BYAPR01MB3702.prod.exchangelabs.com>
 <CAEtu=dNaMFpVDPY-XHO7Kx_HOqPBxx370ksT-dhiQkKQLt3ECQ@mail.gmail.com>
Message-ID: <DCAD5009-A810-4CDB-98EA-7D25A142A5FF@osu.edu>

On 7/25/18, 3:04 PM, "dev on behalf of Tom Scavo" <dev-bounces at shibboleth.net on behalf of trscavo at gmail.com> wrote:

> Btw, Guava is mostly redundant at this point due to the introduction
> of the java.util.function package in Java 8, but the two approaches
> are similar in spirit, so I guess it doesn?t matter.

The IdP is built with Java 7, not 8.

-- Scott