users Digest, Vol 25, Issue 134
Gilles Badouet
badouetg at uni.coventry.ac.uk
Tue Jul 30 13:44:58 EDT 2013
Hi Nate,
Thanks for the information about transientID.
Regarding uid, I have checked all and evreything seems ok, that attribute is still not visible like others when I browse https://.../Shibboleth.sso/Session.
Below is an extract of some debug lines related to attributes within idp-process, I guess it is just a trace like the previous one related to transientID. Apart from that I cant see any other log message indicating a uid issue.
16:24:52.725 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute uid has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:106] - Removing attribute from return set, no more values: eduPersonPrincipalName
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute surname has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute givenName has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute commonName has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute transientId has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute email has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute telephoneNumber has 1 values after filtering
16:24:52.726 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:109] - Attribute mobileNumber has 1 values after filtering
16:24:52.727 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:114] - Filtered attributes for principal yoyo. The following attributes remain: [uid, surname, givenName, commonName, transientId, email, telephoneNumber, mobileNumber]
16:24:52.735 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:527] - Filtering out potential name identifier attributes which can not be encoded by edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
After proper encoding I have this
16:24:52.735 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute uid, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.735 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute surname, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.735 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute givenName, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.735 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute commonName, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.736 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:541] - Retaining attribute transientId which may be encoded to via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.736 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute email, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.736 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute telephoneNumber, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
16:24:52.736 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:546] - Removing attribute mobileNumber, it can not be encoded via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
So I am a bit perplexed about
Kind regards
Gilles Rubens Badouet
_______________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of users-request at shibboleth.net <users-request at shibboleth.net>
Sent: 30 July 2013 17:35
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 134
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at shibboleth.net
You can reach the person managing the list at
users-owner at shibboleth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Re: Attributes TransientID and uid not released
(Nate Klingenstein)
2. Re: Attributes TransientID and uid not released
(Nate Klingenstein)
3. Re: SSL Error: alert internal error (Christopher Peters)
4. Re: login.config to use private-CA-issued certificate
(Christopher Bongaarts)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Jul 2013 16:28:03 +0000
From: Nate Klingenstein <ndk at internet2.edu>
Subject: Re: Attributes TransientID and uid not released
To: Shib Users <users at shibboleth.net>
Message-ID: <EF51664C-5B1D-4E87-B066-3101592CE5F6 at internet2.edu>
Content-Type: text/plain; charset="us-ascii"
Gilles,
I think this is normal behavior. The transientId should not be sent as an attribute, but instead as a NameID in your assertions. Your log messages are consistent with that occurring. Is there something that makes you believe the SP is not receiving a transient name identifier in the Subject of the SAML assertion?
See down further in your logs:
11:57:48.653 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:541] - Retaining attribute transientId which may be encoded to via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
11:57:48.653 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:566] - Filtering out potential name identifier attributes which do not support one of the following formats: [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]
11:57:48.654 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:868] - Using attribute 'transientId' supporting NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' to create the NameID for relying party 'https://sp.testshib.org/shibboleth-sp'
Thanks,
Nate.
On Jul 30, 2013, at 15:51 , Gilles Badouet wrote:
> Hi all,
>
> All my configured attributes are released apart from TransientID and uid.
> Does the TransientID has anything to do with uid (username)?
>
> The debug line seemed to be related to that issue is:
> DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:263] -Attribute transientId was not encoded (filtered by query, or no SAML2AttributeEncoder attached).
>
> Below is my transiendId attribute in attribute-resolver.xml:
> <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId">
> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>
> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
> </resolver:AttributeDefinition>
>
> And in attribute-filter.xml
> <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
> <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
> <afp:AttributeRule attributeID="transientId">
> <afp:PermitValueRule xsi:type="basic:ANY"/>
> </afp:AttributeRule>
> </afp:AttributeFilterPolicy>
>
>
>
>
>
>
>
>
> Kind regards
>
>
> Gilles Rubens Badouet
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
------------------------------
Message: 2
Date: Tue, 30 Jul 2013 16:30:33 +0000
From: Nate Klingenstein <ndk at internet2.edu>
Subject: Re: Attributes TransientID and uid not released
To: Shib Users <users at shibboleth.net>
Message-ID: <CFD818A4-2E7F-4E1E-9A1D-33E25E8C80A9 at internet2.edu>
Content-Type: text/plain; charset="us-ascii"
I should add, your UID problems have nothing to do with your transientId question. They are probably real and may be caused by underlying issues such as no UID being present in the upstream data source, or the attribute filters being written a certain way, or an SP discarding the UID for some reason. Your IdP logs will tell you which of these is the case.
On Jul 30, 2013, at 16:28 , Nate Klingenstein wrote:
> Gilles,
>
> I think this is normal behavior. The transientId should not be sent as an attribute, but instead as a NameID in your assertions. Your log messages are consistent with that occurring. Is there something that makes you believe the SP is not receiving a transient name identifier in the Subject of the SAML assertion?
>
> See down further in your logs:
>
> 11:57:48.653 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:541] - Retaining attribute transientId which may be encoded to via edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
>
> 11:57:48.653 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:566] - Filtering out potential name identifier attributes which do not support one of the following formats: [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]
>
> 11:57:48.654 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:868] - Using attribute 'transientId' supporting NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' to create the NameID for relying party 'https://sp.testshib.org/shibboleth-sp'
>
> Thanks,
> Nate.
>
> On Jul 30, 2013, at 15:51 , Gilles Badouet wrote:
>
>> Hi all,
>>
>> All my configured attributes are released apart from TransientID and uid.
>> Does the TransientID has anything to do with uid (username)?
>>
>> The debug line seemed to be related to that issue is:
>> DEBUG [edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority:263] -Attribute transientId was not encoded (filtered by query, or no SAML2AttributeEncoder attached).
>>
>> Below is my transiendId attribute in attribute-resolver.xml:
>> <resolver:AttributeDefinition id="transientId" xsi:type="ad:TransientId">
>> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier" nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>
>> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
>> </resolver:AttributeDefinition>
>>
>> And in attribute-filter.xml
>> <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
>> <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
>> <afp:AttributeRule attributeID="transientId">
>> <afp:PermitValueRule xsi:type="basic:ANY"/>
>> </afp:AttributeRule>
>> </afp:AttributeFilterPolicy>
>>
>>
>>
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>> Gilles Rubens Badouet
>>
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>
------------------------------
Message: 3
Date: Tue, 30 Jul 2013 09:31:21 -0700
From: Christopher Peters <cjpeters at uci.edu>
Subject: Re: SSL Error: alert internal error
To: Shib Users <users at shibboleth.net>
Message-ID:
<CAGocuEt+2_CDgg=PkXWm5bpRr3Efx5vLXod+YUVe0hu+n0rLWg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
So I got this to work on my test machine. I installed JRE 1.7, and it
still proposed the bad certificate error when trying to connect using
openssl s_client -connect ... regardless of protocol specified.
So I started looking at my Tomcat configuration to see if there was
something amiss. I compared my config to the page:
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
and found that I had set clientAuth = "true" instead of "want". I looked
up what that does and apparently it requires a valid cert by supplied
before a transaction can be established. I turned this to want and now it
works just fine.
To my way of thinking, this means the "alert bad certificate" error isn't
saying the cert the server is giving out is bad, but the one it's receiving
is bad (or non-existent). I don't know if that's correct, but I do know
this new setting is working out and if someone with expertise cares to give
a little more explanation on why I would love to hear it.
Otherwise, I can just move forward now. I think this is fixed :)
p.s. I am running on Solaris 10. Thanks to the guy who suggested the Linux
fix, but it wasn't applicable.
On Mon, Jul 29, 2013 at 3:02 PM, Christopher Peters <cjpeters at uci.edu>wrote:
> Well, we are using it for the SSO transaction (which uses Apache), but I
> see your point. I don't really know how Java's dependencies are set up,
> but if you say it's not relying on OSSL, I will take your word for it.
> That makes life much simpler anyway.
>
> As for the SSL thing, I have a server mirrored on another system and I can
> set it up with 1.7 and see if I can get an OpenSSL connection to Tomcat on
> 8443. I will give that a shot and let you know what I find out.
>
> Chris
>
>
> On Mon, Jul 29, 2013 at 2:50 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
>> On 7/29/13 5:47 PM, "Christopher Peters" <cjpeters at uci.edu> wrote:
>>
>> >I will work on upgrading Java to 1.7 and possibly OpenSSL and see if that
>> >fixes things. We do have a rather old version of OpenSSL on the system,
>> >and the related libraries. And, of course, an old version of Java.
>>
>> You're not using OpenSSL, that's not relevant.
>>
>> The bad cert error isn't the expiration, we're talking protocol level
>> issues here. OpenSSL's s_client doesn't care about the dates or the
>> validity, it's just trying to negotiate the connection.
>>
>> -- Scott
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
>
> --
> Chris Peters
> Middleware Services Developer
> Office of Information Technology - NSP
> (949) 824-6845
> cjpeters at uci.edu
>
--
Chris Peters
Middleware Services Developer
Office of Information Technology - NSP
(949) 824-6845
cjpeters at uci.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130730/865cdeb0/attachment-0001.html
------------------------------
Message: 4
Date: Tue, 30 Jul 2013 11:34:40 -0500
From: Christopher Bongaarts <cab at umn.edu>
Subject: Re: login.config to use private-CA-issued certificate
To: users at shibboleth.net
Message-ID: <51F7EB20.1070909 at umn.edu>
Content-Type: text/plain; charset="iso-8859-1"
On 7/29/2013 7:16 PM, David Bantz wrote:
> Caused by: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
> ...
>
> /What are the possible sources of this failure other than having been
> provided the wrong certificate for the server? Do I ALSO need to
> import the issuing CA certificate? Use a different certificate file
> format? .../
If there are intermediate certificates in the chain that the server is
using, and their server is not configured to send the intermediate certs
during SSL negotiation, and you're only trusting the root CA, then this
can happen.
You can work around it by adding the intermediate(s) to your cert store,
but the proper fix is for the server folks to configure SSL to send the
chain (assuming this is the problem).
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130730/3de01c86/attachment.html
------------------------------
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
End of users Digest, Vol 25, Issue 134
**************************************
More information about the users
mailing list