idp-war-3.4.4.war in Maven Repo is bad

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

idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
Hey Guys,

Looks like the idp-war for 3.4.4 you published to Maven is missing all
the jars needed for the new ldaptive change.

When I compare the idp-war-3.4.4 from Maven to the idp.war from the
Windows Installer the following jars are missing from the version in
Maven...

unboundid-ldapsdk-4.0.9.jar
metrics-jvm-3.1.2.jar
logback-classic-1.2.3.jar
ldaptive-unboundid-1.0.13.jar
jcl-over-slf4j-1.7.25.jar

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: idp-war-3.4.4.war in Maven Repo is bad

Rod Widdowson
> Looks like the idp-war for 3.4.4 you published to Maven is missing all
> the jars needed for the new ldaptive change.

I'm no expert on our mvn packaging but it looks as though idp-war is what is needed to run the IdP.  These extra packages get added
during the build of the distribution (which puts together the distributed bits)

What are you trying to achieve? There may be a better way to get it done.

/Rod

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
Hi Rod,

Today is your lucky day, I happen to know Maven very well.  I'll send
you a patch file that will fix it.

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
On Wed, Jun 12, 2019 at 4:22 AM Rod Widdowson <[hidden email]> wrote:

>
> > Looks like the idp-war for 3.4.4 you published to Maven is missing all
> > the jars needed for the new ldaptive change.
>
> I'm no expert on our mvn packaging but it looks as though idp-war is what is needed to run the IdP.  These extra packages get added
> during the build of the distribution (which puts together the distributed bits)
>
> What are you trying to achieve? There may be a better way to get it done.
>
> /Rod
>
> --
> To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
> Today is your lucky day, I happen to know Maven very well.  I'll send you a
> patch file that will fix it.

Nothing to fix, that artifact is not for anybody else's use.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
In reply to this post by Dan McLaughlin
> When I compare the idp-war-3.4.4 from Maven to the idp.war from the
> Windows Installer the following jars are missing from the version in Maven...
>
> unboundid-ldapsdk-4.0.9.jar
> metrics-jvm-3.1.2.jar
> logback-classic-1.2.3.jar
> ldaptive-unboundid-1.0.13.jar
> jcl-over-slf4j-1.7.25.jar

All of those are added by the assembly of the distribution module, they are not in idp-war. They're in "the war" that is built by the installed software.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
In reply to this post by Cantor, Scott E.
Hey Scott,

Understood, but unfortunately someone published the idp-war artifact
to Shibboleth's Public Maven repository, and we used it.  We use the
idp-war as a dependency as part of our automated IDP application
deployment using Maven and we pull in the war as part of our build so
we can add our dependencies for our custom attribute resolver
extension.  I've worked around it for now by adding the missing
dependencies in our Maven build, so this isn't a show stopper by any
means, however I still think it should eventually be corrected on your
end because it's wrong from a Maven perspective.  The missing jar's
really are runtime dependencies for the idp-war to function if you
want to use the new UnboundIDProvider in 3.4.4  and they should be
defined as such in the idp-war pom.

The problem stems from the fact that someone added what are valid
runtime dependencies for the idp-war to the idp-distribution and then
they used a plugin to extract the runtime dependencies into the war as
part of the idp-distribution build. They actually did it for the
logging runtime dependencies and add the ldaptive dependencies into
that same plugin execution.  The current approach is contrary to
everything Maven is about, all dependencies should be defined in the
module that depends on them, not copied in using a plugin...you might
as well move back to Ant if you're going to do that.

On a side note the step to add idp.ldaptive.provider =
org.ldaptive.provider.unboundid.UnboundIDProvider to the
ldap.properties in 3.4.4 doesn't just work as the release notes would
lead you to believe.  I haven't had a chance to debug it yet, but in
short we start getting errors similar to what you'd get if you had an
invalid attribute-resolver.xml.  Remove the property and everything
works fine.

I've attached a patch that will fix the idp-war.

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

On Wed, Jun 12, 2019 at 2:37 PM Cantor, Scott <[hidden email]> wrote:

>
> > Today is your lucky day, I happen to know Maven very well.  I'll send you a
> > patch file that will fix it.
>
> Nothing to fix, that artifact is not for anybody else's use.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

Moved_Runtime_dependencies_for_idp-war_out_of_idp-distribution_and_into_idp-war_where_they.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Ian Young-3
On 13 Jun 2019, at 00:44, Dan McLaughlin <[hidden email]> wrote:

The missing jar's
really are runtime dependencies for the idp-war to function if you
want to use the new UnboundIDProvider in 3.4.4  and they should be
defined as such in the idp-war pom.

I think what you may be missing -- for the question of the logging dependencies in particular -- is that logback is not the only possible logging back-end. The intention of the way we have the dependencies set up is to allow the possibility of other logging back-ends to be used instead, in contexts where that's appropriate. So we're introducing logback into the product as late as possible in the process.

I'm not saying that this intention is 100% realised in our current setup: in fact, there's an outstanding JIRA case pointing out some irregularities in the way things are arranged. Also, your proposed patch includes some other dependency issues that may be worth looking at independently. But the right action is not as simple as just adding everything to idp-war's POM.

    -- Ian




--
To unsubscribe from this list send an email to [hidden email]

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
In reply to this post by Dan McLaughlin
> They actually did it for the logging runtime dependencies and add the ldaptive dependencies into
> that same plugin execution.

They are the same issue; the software as it stands does not require any specific LDAP or logging implementation, and it is only our distribution that provides specific instantiations that match our defaults, as Ian noted. Whatever is correct for the logging is also conceptually correct for the LDAP jars, particularly in V3 where Unbound isn't the default.

> On a side note the step to add idp.ldaptive.provider =
> org.ldaptive.provider.unboundid.UnboundIDProvider to the
> ldap.properties in 3.4.4 doesn't just work as the release notes would
> lead you to believe.

In most cases, that works. In other cases, you may have JNDI-specific assumptions that have to be adjusted, but that's a local matter. In all cases, it does what the Release Notes are trying to say, which is that it does switch the provider without having to do so externally. It doesn't mean to say that's the only possible change needed, that's why it refers to the other page.
 
-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
I get where you're coming from.  Maybe update the release notes to let
people know that if they got the idp-war from Maven they will still
need to download and install the ldaptive jars and put them in their
classpath as was discussed in one of the related ticket on the topic.

As to why adding the new property is causing failures, I still haven't
figured out why yet. It looks like I narrowed down the failures to
something related to us using JAASAuthnConfig.  If you are using
LDAPAuthnConfig then it works.    Unfortunately we have to use
JAASAuthn because there's no other way to chain different user
repository types using the LDAPAuthn config and we have the need to
authenticate users against a database user repository and only if they
aren't in the database do we try LDAP.  The only way we could figure
out a way chain a database and LDAP was using JAAS Authn. One thing to
note is that it doesn't seem to break the JAAS Authn, but it would
seem that something with the attribute resolution breaks. We can see
in the logs that the login is successful, it's not until it gets to
the attribute resolution that things error out.   Anyways, still
digging, but if you think of anything that might explain the behavior
I'm seeing I'd be open to any suggestions.

Thanks again!

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

On Thu, Jun 13, 2019 at 8:37 AM Cantor, Scott <[hidden email]> wrote:

>
> > They actually did it for the logging runtime dependencies and add the ldaptive dependencies into
> > that same plugin execution.
>
> They are the same issue; the software as it stands does not require any specific LDAP or logging implementation, and it is only our distribution that provides specific instantiations that match our defaults, as Ian noted. Whatever is correct for the logging is also conceptually correct for the LDAP jars, particularly in V3 where Unbound isn't the default.
>
> > On a side note the step to add idp.ldaptive.provider =
> > org.ldaptive.provider.unboundid.UnboundIDProvider to the
> > ldap.properties in 3.4.4 doesn't just work as the release notes would
> > lead you to believe.
>
> In most cases, that works. In other cases, you may have JNDI-specific assumptions that have to be adjusted, but that's a local matter. In all cases, it does what the Release Notes are trying to say, which is that it does switch the provider without having to do so externally. It doesn't mean to say that's the only possible change needed, that's why it refers to the other page.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
> I get where you're coming from.  Maybe update the release notes to let people
> know that if they got the idp-war from Maven they will still need to download
> and install the ldaptive jars and put them in their classpath as was discussed in
> one of the related ticket on the topic.

I don't plan to, but if somebody else wants to add material about something we don't support, the wiki is not limited to us to edit.

> As to why adding the new property is causing failures, I still haven't figured out
> why yet. It looks like I narrowed down the failures to something related to us
> using JAASAuthnConfig.

I use JAAS with it FWIW.

> was using JAAS Authn. One thing to note is that it doesn't seem to break the
> JAAS Authn, but it would seem that something with the attribute resolution
> breaks.

Those are unrelated, so it can't be caused by JAAS but then affect attribute resolution. I think you're misdiagnosing something. An attribute resolver issue is not connected to how you authenticate.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
With the root logger set to ALL I was able to use Beyond Compare to
diff the login and attribute resolution and the only difference I can
find is that the objectGUID is getting corrupted with UnboundID ID is
used.  When using JNDI we set   <LDAPProperty
name="java.naming.ldap.attributes.binary" value="objectGUID"/>, but
that seems to be getting ignored by the UnboundID  provider.

[objectGUID[GqzJ3AninkS/SGDsawhnYg==]]
[objectGUID[ ��� �D�H`�k gb]]


--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

On Thu, Jun 13, 2019 at 5:51 PM Cantor, Scott <[hidden email]> wrote:

>
> > I get where you're coming from.  Maybe update the release notes to let people
> > know that if they got the idp-war from Maven they will still need to download
> > and install the ldaptive jars and put them in their classpath as was discussed in
> > one of the related ticket on the topic.
>
> I don't plan to, but if somebody else wants to add material about something we don't support, the wiki is not limited to us to edit.
>
> > As to why adding the new property is causing failures, I still haven't figured out
> > why yet. It looks like I narrowed down the failures to something related to us
> > using JAASAuthnConfig.
>
> I use JAAS with it FWIW.
>
> > was using JAAS Authn. One thing to note is that it doesn't seem to break the
> > JAAS Authn, but it would seem that something with the attribute resolution
> > breaks.
>
> Those are unrelated, so it can't be caused by JAAS but then affect attribute resolution. I think you're misdiagnosing something. An attribute resolver issue is not connected to how you authenticate.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
On 6/14/19, 3:47 AM, "dev on behalf of Dan McLaughlin" <[hidden email] on behalf of [hidden email]> wrote:

>  When using JNDI we set   <LDAPProperty
> name="java.naming.ldap.attributes.binary" value="objectGUID"/>, but
> that seems to be getting ignored by the UnboundID  provider.

Yes, that's a JNDI property, it would not work with anything else. That's what the page we created about this change mentions, JNDI specific property issues that would have to be addressed. Usually it's just timeouts and things like that.

If Unbound doesn't have its own, and ldaptive doesn't have a "generic" one, then I wouldn't have any suggestion, and I don't know what they would be if they do exist. I'd post to -users, as this isn't a dev topic, Daniel might know.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Dan McLaughlin
Hey Scott,

Well it looks like there is a binaryAttributes property in the
Ldaptive SDK, not in the UnboundID provider, but it's not exposed in
the IDP code so we can set it.  I did find some properties in the
ldaptive test source. I tried adding them as you can see in the logs
below, but no
luck.  Looking at the ldap ldaptive and unboundid source there is
support for binaryAttributes and derefAliases, but neither look like
you can set them using a Java System Properties.  You can see in the
log entry below that I've set
org.ldaptive.binaryAttributes=objectGUID,
org.ldaptive.connectTimeout=PT8S, org.ldaptive.derefAliases=NEVER,
which I found in the ldaptive test source.

When the IDP authentication and attribute resolution completes the
user is redirected back the SP and the SP logs show the following
ERROR...

2019-06-14 00:44:32 ERROR Shibboleth.SSO.SAML2 [3] [default]: failed
to decrypt assertion: XMLSecurity exception while decrypting: Errors
occurred during de-serialisation of decrypted element content
2019-06-14 00:44:32 WARN Shibboleth.SSO.SAML2 [3] [default]: error
processing incoming assertion: A valid authentication statement was
not found in the incoming message.

Why simply changing out the LDAP provider to use the UnboundID causes
this to happen I have no clue, but the only difference I've found in
the IDP logs is the objectGUID coming back messed up because I can't
find a way to configure the binaryAttributes property for Ldaptive.
Looking at all the code for the IDP, ldaptive, and the unboundid
provider it would seem that Shibboleth will have to make code changes
to be able to set properties that we used to be able to set using the
jndi properties, ex...binaryAttributes and derefAliases.

These are the logs showing where you can see that I set the
properties, but in the search request you can see that
binaryAttributes is still set to null, which is the default value
based on the Ldaptive source and documentation.

DEBUG [org.ldaptive.SearchOperation:138] - execute
request=[org.ldaptive.SearchRequest@-430563002::baseDn=DC=mydomain,DC=com,
searchFilter=[org.ldaptive.SearchFilter@-142096805::filter=(&(sAMAccountName=jsmith)(objectclass=user)),
parameters={}], returnAttributes=[objectGUID, sAMAccountName,
department, sn, givenName, mail, telephoneNumber],
searchScope=SUBTREE, timeLimit=3000, sizeLimit=1, derefAliases=null,
typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED,
searchEntryHandlers=[[org.ldaptive.handler.DnAttributeEntryHandler@-1580910376::dnAttributeName=entryDN,
addIfExists=false]], searchReferenceHandlers=null, controls=null,
followReferrals=false, intermediateResponseHandlers=null] with
connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1153421247::config=[org.ldaptive.ConnectionConfig@1903478003::ldapUrl=ldap://ldap1:3268,
connectTimeout=3000, responseTimeout=3000,
sslConfig=[org.ldaptive.ssl.SslConfig@1794675335::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2@25db2f4f,
trustManagers=null, hostnameVerifier=null,
hostnameVerifierConfig=null, enabledCipherSuites=null,
enabledProtocols=null, handshakeCompletedListeners=null],
useSSL=false, useStartTLS=false,
connectionInitializer=[org.ldaptive.BindConnectionInitializer@1920649635::bindDn=CN=BINDUSER,OU=Users,DC=mydomain,DC=com,
bindSaslConfig=null, bindControls=null]],
providerConnectionFactory=[org.ldaptive.provider.unboundid.UnboundIDConnectionFactory@1799602403::metadata=[ldapUrl=ldap://ldap1:3268,
count=6], providerConfig=[org.ldaptive.provider.unboundid.UnboundIDProviderConfig@12825950::operationExceptionResultCodes=[SERVER_DOWN],
properties={org.ldaptive.binaryAttributes=objectGUID,
org.ldaptive.connectTimeout=PT8S, org.ldaptive.derefAliases=NEVER},
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy@5b5a5202,
controlProcessor=org.ldaptive.provider.ControlProcessor@524ad520,
connectionOptions=null, socketFactory=null, sslSocketFactory=null,
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED]]],
providerConnection=org.ldaptive.provider.unboundid.UnboundIDConnection@25469a50]
DEBUG [org.ldaptive.provider.unboundid.UnboundIDConnection:659] -
performing search: SearchRequest(baseDN='DC=mydomain,DC=com',
scope=SUB, deref=NEVER, sizeLimit=1, timeLimit=3000,
filter='(&(sAMAccountName=jsmith)(objectclass=user))',
attrs={objectGUID, sAMAccountName, department, sn, givenName, mail,
telephoneNumber})
DEBUG [org.ldaptive.provider.unboundid.UnboundIDConnection:663] -
created response: [org.ldaptive.Response@1169478761::result=null,
resultCode=SUCCESS, message=null, matchedDn=null,
responseControls=null, referralURLs=[], messageId=3]
DEBUG [org.ldaptive.SearchOperation:168] - execute
response=[org.ldaptive.Response@960201973::result=[org.ldaptive.SearchResult@1216789946::entries=[[dn=CN=jsmith,OU=Users,DC=mydomain,DC=com[[telephoneNumber[(555)
555-5555]], [mail[[hidden email]]], [givenName[Joe]],
[objectGUID[ ��� �D�H`�k gb]], [sn[Smith]],
[department[IT]], [entryDN[CN=jsmith,OU=Users,DC=mydomain,DC=com]],
[sAMAccountName[jsmith]]], responseControls=null, messageId=3]],
references=[]], resultCode=SUCCESS, message=null, matchedDn=null,
responseControls=null, referralURLs=[], messageId=3] for
request=[org.ldaptive.SearchRequest@-430563002::baseDn=DC=mydomain,DC=com,
searchFilter=[org.ldaptive.SearchFilter@-142096805::filter=(&(sAMAccountName=jsmith)(objectclass=user)),
parameters={}], returnAttributes=[objectGUID, sAMAccountName,
department, sn, givenName, mail, telephoneNumber],
searchScope=SUBTREE, timeLimit=3000, sizeLimit=1, derefAliases=null,
typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED,
searchEntryHandlers=[[org.ldaptive.handler.DnAttributeEntryHandler@-1580910376::dnAttributeName=entryDN,
addIfExists=false]], searchReferenceHandlers=null, controls=null,
followReferrals=false, intermediateResponseHandlers=null] with
connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1153421247::config=[org.ldaptive.ConnectionConfig@1903478003::ldapUrl=ldap://ldap1:3268,
connectTimeout=3000, responseTimeout=3000,
sslConfig=[org.ldaptive.ssl.SslConfig@1794675335::credentialConfig=org.ldaptive.ssl.CredentialConfigFactory$2@25db2f4f,
trustManagers=null, hostnameVerifier=null,
hostnameVerifierConfig=null, enabledCipherSuites=null,
enabledProtocols=null, handshakeCompletedListeners=null],
useSSL=false, useStartTLS=false,
connectionInitializer=[org.ldaptive.BindConnectionInitializer@1920649635::bindDn=CN=BINDUSER,OU=Users,DC=mydomain,DC=com,
bindSaslConfig=null, bindControls=null]],
providerConnectionFactory=[org.ldaptive.provider.unboundid.UnboundIDConnectionFactory@1799602403::metadata=[ldapUrl=ldap://ldap1:3268,
count=6], providerConfig=[org.ldaptive.provider.unboundid.UnboundIDProviderConfig@12825950::operationExceptionResultCodes=[SERVER_DOWN],
properties={org.ldaptive.binaryAttributes=objectGUID,
org.ldaptive.connectTimeout=PT8S, org.ldaptive.derefAliases=NEVER},
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$ActivePassiveConnectionStrategy@5b5a5202,
controlProcessor=org.ldaptive.provider.ControlProcessor@524ad520,
connectionOptions=null, socketFactory=null, sslSocketFactory=null,
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED]]],
providerConnection=org.ldaptive.provider.unboundid.UnboundIDConnection@25469a50]








--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.


--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
[hidden email]
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
On Fri, Jun 14, 2019 at 11:42 AM Dan McLaughlin
<[hidden email]> wrote:

>
> Hey Daniel,
>
> I've been searching the UnboundID LDAP SDK docs for a list of Java
> System Properties that I can set when using the Shibboleth IDP and I
> can't find a list in the docs anywhere. Would you mind pointing me in
> the right direction?  Specifically I need to set the equivalent of
> java.naming.ldap.derefAliases=never,
> java.naming.ldap.attributes.binary=objectGUID,
> com.sun.jndi.ldap.connect.timeout=500.
>
> --
>
> Thanks,
>
> Dan McLaughlin
> Technology Consortium, LLC
> [hidden email]
> mobile: 512.633.8086
> http://www.tech-consortium.com
>
> NOTICE: This e-mail message and all attachments transmitted with it
> are for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is strictly prohibited. The contents of
> this e-mail are confidential and may be subject to work product
> privileges. If you are not the intended recipient, please contact the
> sender by reply e-mail and destroy all copies of the original message.
>
> On Fri, Jun 14, 2019 at 9:12 AM Cantor, Scott <[hidden email]> wrote:
> >
> > On 6/14/19, 3:47 AM, "dev on behalf of Dan McLaughlin" <[hidden email] on behalf of [hidden email]> wrote:
> >
> > >  When using JNDI we set   <LDAPProperty
> > > name="java.naming.ldap.attributes.binary" value="objectGUID"/>, but
> > > that seems to be getting ignored by the UnboundID  provider.
> >
> > Yes, that's a JNDI property, it would not work with anything else. That's what the page we created about this change mentions, JNDI specific property issues that would have to be addressed. Usually it's just timeouts and things like that.
> >
> > If Unbound doesn't have its own, and ldaptive doesn't have a "generic" one, then I wouldn't have any suggestion, and I don't know what they would be if they do exist. I'd post to -users, as this isn't a dev topic, Daniel might know.
> >
> > -- Scott
> >
> >
> > --
> > To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
On 6/14/19, 7:13 PM, "dev on behalf of Dan McLaughlin" <[hidden email] on behalf of [hidden email]> wrote:

> Looking at all the code for the IDP, ldaptive, and the unboundid
> provider it would seem that Shibboleth will have to make code changes
> to be able to set properties that we used to be able to set using the
> jndi properties, ex...binaryAttributes and derefAliases.

That's above and beyond, I suspect Daniel either knows that or would have been able to bottom that out. The best way to deal with it is to file the issue so it gets addressed. I know that people that use AD do have cases where binary attribute handling come into play.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Etienne Dysli Metref
In reply to this post by Dan McLaughlin

On 13.06.19 01:44, Dan McLaughlin wrote:
> We use the idp-war as a dependency as part of our automated IDP
> application deployment using Maven and we pull in the war as part of
> our build so we can add our dependencies for our custom attribute
> resolver extension.
Hey Dan thanks for bringing this up! I'd also like to use idp-war the
same way to package an IdP with our extensions, because having our JARs
copied over to the IdP then rebuilding the WAR is getting cumbersome
when you have 2-3 CI jobs each dropping it's own JAR there...

On the other hand, I understand the devs reservations regarding the
runtime implementations of the used APIs. We just need to keep track of
these to remember including them in Maven dependencies.

  Etienne


--
To unsubscribe from this list send an email to [hidden email]

signature.asc (895 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
On 6/17/19, 2:33 PM, "dev on behalf of Etienne Dysli Metref" <[hidden email] on behalf of [hidden email]> wrote:

> Hey Dan thanks for bringing this up! I'd also like to use idp-war the
> same way to package an IdP with our extensions, because having our JARs
> copied over to the IdP then rebuilding the WAR is getting cumbersome
> when you have 2-3 CI jobs each dropping it's own JAR there...

I don't think we're taking a particular position on people doing that general thing or not, and if there were a way to get to a place where we can support and document a specific approach, that's fine. Whether it involves what is currently labeled idp-war or not is immaterial.

In general terms supporting extensions better is a known problem, but we don't have a well-baked set of requirements around what we need to do at this point to accomplish "better".

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Etienne Dysli Metref
In reply to this post by Ian Young-3
On 13/06/2019 15.02, Ian Young wrote:
> I think what you may be missing -- for the question of the logging
> dependencies in particular -- is that logback is not the only possible
> logging back-end. The intention of the way we have the dependencies set
> up is to allow the possibility of other logging back-ends to be used
> instead, in contexts where that's appropriate.

Coming back to this (in IDP-1481), I find it a rather weak argument. Do
you know of anyone going through the trouble of unpacking the
distributed idp.war to remove Logback because they prefer to use another
SLF4J implementation?

> So we're introducing logback into the product as late as possible in
> the process.
That's a commendable intention, but the resulting WAR file isn't
reusable by Maven, thereby thwarting other people's effort at automation.

  Etienne


--
To unsubscribe from this list send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
On 8/23/19, 4:35 AM, "dev on behalf of Etienne Dysli Metref" <[hidden email] on behalf of [hidden email]> wrote:

> Coming back to this (in IDP-1481), I find it a rather weak argument. Do
> you know of anyone going through the trouble of unpacking the
> distributed idp.war to remove Logback because they prefer to use another
> SLF4J implementation?

logback isn't the only example of "missing" jars, but you wouldn't have to remove them necessarily, but that's also an indictment of the fact that we don't currently support the removal of jars in the overall install process.
 
> That's a commendable intention, but the resulting WAR file isn't
> reusable by Maven, thereby thwarting other people's effort at automation.

The automation is already a problem if you're not running the installer because of upgrades, as I noted. You commented " Indeed configuration isn't taken into account here, it's left for the deployer to manage separately (not unfamiliar to those using Docker)."

But there's no way for a deployer to manage the configuration in that case since the installer is bult to manage the war, not just the configuration files.

What we have is just not designed to work with these sorts of deployment strategies and since none of us using the IdP for real understand them well, we're terribly positioned to support them at this point. But my thought was that we could compromise by adding some kind of additional overlay artifact that could be a bridge between what we need now and what people are trying to do with it.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Etienne Dysli Metref
On 23/08/2019 16.28, Cantor, Scott wrote:
> But my thought was that we could compromise by adding some kind of
> additional overlay artifact that could be a bridge between what we
> need now and what people are trying to do with it.

I've proposed patch in IDP-1481 to make such an additional artifact.
(The patch is against 4.0.0-SNAPSHOT, but can be easily adapted to 3.4.)
Would this WAR file be interesting to other IdP deployers?

  Etienne


--
To unsubscribe from this list send an email to [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: idp-war-3.4.4.war in Maven Repo is bad

Cantor, Scott E.
On 8/26/19, 4:45 AM, "dev on behalf of Etienne Dysli Metref" <[hidden email] on behalf of [hidden email]> wrote:

> I've proposed patch in IDP-1481 to make such an additional artifact.
> (The patch is against 4.0.0-SNAPSHOT, but can be easily adapted to 3.4.)

I think that's probably what I had in mind, but it will be to the rest of the team to decide whether this seems like a good direction once they can take a look at it.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]