users Digest, Vol 69, Issue 29 - 3. Re: Need Assistance on Releasing Attribute to SP who is part

[Edward Patri]

Hi David,

Please see below, 

<resolver:AttributeDefinition xsi:type="ad:Simple" id="mail" sourceAttributeID="mail">
        <resolver:Dependency ref="myLDAP" />
		<resolver:Dependency ref="myLDAP2" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
    </resolver:AttributeDefinition>

We have successfully released this attribute to several other SP's with no problem. This is the first time we are releasing to an SP who is using InCommon MetaData. 

Message: 3
Date: Tue, 7 Mar 2017 08:03:16 -0900
From: IAM David Bantz <dabantz at alaska.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Need Assistance on Releasing Attribute to SP who is part
	of InCommon
Message-ID:
	<CAJ9XvwGt8CAeb2TNaz0S+p3iYiPuX0pTpwKX4H97ENgqQtrZJg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

What's your attribute resolver for attribute with id "mail"?

On Tue, Mar 7, 2017 at 7:58 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 3/7/17, 11:44 AM, "users on behalf of Edward Patri" <
> users-bounces at shibboleth.net on behalf of Edward.Patri at csi.cuny.edu>
> wrote:
>
> > How would I go about releasing attributes to an specific SP who is a
> member of InCommon.
>
> You already did it. If you're having issues, use your logs, but chances
> are the attribute simply doesn't exist and you're having resolver issues.
>
> Also your policy is needlessly verbose.
>
> <AttributeFilterPolicy id="releaseToOrgSync">
>  <PolicyRequirementRule xsi:type="Requester" value=https://orgsync.com/
> shibboleth-sp />
>   <AttributeRule attributeID="mail" permitAny="true" />
> </AttributeFilterPolicy>
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170307/3e517fe4/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 7 Mar 2017 12:05:04 -0500
From: Tom Scavo <trscavo at gmail.com>
To: Shib Users <users at shibboleth.net>
Subject: Re: Need Assistance on Releasing Attribute to SP who is part
	of InCommon
Message-ID:
	<CAEtu=dOj+im3LjKUSCzt+R3VFUcP-cJUPcqieBDnMM=9hZh+mw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 7, 2017 at 11:44 AM, Edward Patri <Edward.Patri at csi.cuny.edu> wrote:
>
> <MetadataProvider id="ICMD" xsi:type="FileBackedHTTPMetadataProvider"
> xmlns="urn:mace:shibboleth:2.0:metadata"
>
> metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml"
>                   minRefreshDelay="PT5M"
>                   maxRefreshDelay="PT1H"
>                   refreshDelayFactor="0.75"
>                   backingFile="C:\Program Files
> (x86)\Shibboleth\IdP\metadata\InCommon-metadata.xml"/>

If that's all there is to your MetadataProvider, then that is
insecure. See this wiki page for a secure metadata configuration that
verifies the signature on the file and validates the validUntil
expiration date: https://spaces.internet2.edu/x/XAQjAQ

Tom


------------------------------

Message: 5
Date: Tue, 7 Mar 2017 09:17:36 -0800 (PST)
From: Jim Fox <fox at washington.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth audit logging - Fails to capture client
	browser IP (x-forwarded-for) in IdP/Tomcat
Message-ID: <alpine.DEB.2.20.1703070916220.4548 at x315>
Content-Type: text/plain; charset=US-ASCII; format=flowed


In addition to the other suggestions you really ought to set the 
internalProxies attribute of the RemoteIpValve.  That's how you prevent 
just anyone from setting the x-forwarded-for header.

Jim


On Tue, 7 Mar 2017, Kevin Foote wrote:

> Date: Tue, 7 Mar 2017 08:54:33
> From: Kevin Foote <kevin.foote at colorado.edu>
> To: Shib Users <users at shibboleth.net>
> Reply-To: Shib Users <users at shibboleth.net>
> Subject: Re: Shibboleth audit logging - Fails to capture client browser IP
>     (x-forwarded-for) in IdP/Tomcat
> 
>
>> On Mar 7, 2017, at 09:50, Petursson, Sigurdur <spetursson at miami.edu> wrote:
>>
>> Thanks Kevin. We are still running IdP version 2.38. Your documentation only applies to version 3 correct?
>
> That version is very unsupported, YMMV. You need to update to the latest software.
>
> The same documentation is available for IdPv2.
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPLogging
>
>
> --------
> thanks
> kevin.foote
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>


------------------------------

Message: 6
Date: Tue, 7 Mar 2017 17:25:47 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: Shibboleth audit logging - Fails to capture client
	browser IP (x-forwarded-for) in IdP/Tomcat
Message-ID: <565289FD-3F3C-4E44-B218-C7CE4C0F303B at osu.edu>
Content-Type: text/plain; charset="utf-8"

On 3/7/17, 12:17 PM, "users on behalf of Jim Fox" <users-bounces at shibboleth.net on behalf of fox at washington.edu> wrote:

> In addition to the other suggestions you really ought to set the
>  internalProxies attribute of the RemoteIpValve.  That's how you prevent
>  just anyone from setting the x-forwarded-for header.

Assuming that whitelists the addresses who can set it, that's a cool feature. Unfortunately the issue I was referring to is that I believe it's possible with some load balancers that support setting it that they don't prevent the client from already setting it and overriding whatever the load balancer might set.

I do not know that F5 does this. I do know that the Citrix NetScaler does. They also refused to fix it.

-- Scott



------------------------------

Subject: Digest Footer

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

------------------------------

End of users Digest, Vol 69, Issue 29
*************************************