Research and Scholarship and filter by relying party

[Jeffrey Crawford]

On Tue, Mar 4, 2014 at 1:24 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 3/4/14, 4:18 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
> >
> >Well okay so if an SP doesn't even get NamedID it's supposed to handle
> >that?
>
> Yes, as a matter of basic input validation.
>

Well therein lies the problem, if we are not sending attributes an app
wants and it behaves badly we might be causing error pages go up with
sensitive information. Not our or InCommons problem yes but it still
doesn't help.

Additionally our current setup makes it very easy for support personal to
know if we are supporting an InCommon application or not. I tested with a
test SP and even though it received no variables it allowed a login. That
would be pretty big change to the way things work today. Especially since
there is not lot of use of InCommon apps currently


>
> >It doesn't look like Metadata Filtering is going to help in this case so
> >It's starting to look like I'm going to have to change from relying-party
> >based to filter based.
>
> I don't see any reason why filtering isn't exactly the solution. You don't
> even need to write Java code, you could build a cron job to pull in
> metadata and run it through an XSLT script.
>

As long as the file is present and being updated the IdP will continue to
read it correct, or did I miss someplace that requires configuration that
the IdP periodically reads the file?

Well this will incur a special kind of madness :). If I may post an
example to work with xlstproc, we want to allow certin entityID's and all
entityID's that are part of RandS (by the way I don't pretend to know xslt
all that well) does this look resonable?:
===========================
<?xml version="1.0" encoding="utf-8"?>
    <xsl:stylesheet
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
      xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
      xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      exclude-result-prefixes="xs md mdattr saml"
      version="1.0">

      <xsl:output method="xml" indent="yes"/>
      <xsl:strip-space elements="*" />

      <!-- Pull in the default stuff -->
      <xsl:template match="@*|node()">
        <xsl:copy>
          <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
      </xsl:template>

      <!-- Very large if statement to make sure we get entries we need -->
      <xsl:template match="md:EntitiesDescriptor/md:EntityDescriptor">
        <xsl:if test="@entityID = 'urn:mace:incommon:ucsc.edu'
   or
                      @entityID = 'https://www2.ucsc.edu/shibboleth'
   or
                      @entityID = 'https://uc.sumtotalsystems.com/shibboleth'
or
                      @entityID = 'https://ucsso.travelprefs.com'
  or

md:Extensions/mdattr:EntityAttributes/saml:Attribute[@Name != '
http://macedir.org/entity-category']/saml:AttributeValue[text()='http://id.incommon.org/category/research-and-scholarship'
]">
          <EntityDescriptor>
            <xsl:apply-templates select="@*|node()"/>
          </EntityDescriptor>
        </xsl:if>
      </xsl:template>

    </xsl:stylesheet>
===========================



>
> -- 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/20140305/c3ffd173/attachment.html