Shibboleth 2.0 IdP slides - Installfest (Edited)
Upcoming SlideShare
Loading in...5
×
 

Shibboleth 2.0 IdP slides - Installfest (Edited)

on

  • 6,693 views

Shibboleth 2.0 Installfest, 1-2 July, Birmingham.

Shibboleth 2.0 Installfest, 1-2 July, Birmingham.

Statistics

Views

Total Views
6,693
Slideshare-icon Views on SlideShare
6,669
Embed Views
24

Actions

Likes
0
Downloads
83
Comments
0

1 Embed 24

http://www.slideshare.net 24

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Shibboleth 2.0 IdP slides - Installfest (Edited) Shibboleth 2.0 IdP slides - Installfest (Edited) Presentation Transcript

    • Installation to SSO Chad La Joie [email_address]
    • Tour of What We Learned
      • SWITCH AAI Demo Page: http://aai-demo.switch.ch
    • Terms: Entity ID
      • A unique identifier for a identity provider ( IdP ) or service provider ( SP )‏
      • In shibboleth 2 the recommended format is a URL
        • idp: https://HOSTNAME/idp/shibboleth
        • sp: http://HOSTNAME/shibboleth
    • Terms: Relying Party
      • The SAML peer to which the IdP is communicating.
      • In all existing cases, the relying party of the IdP is always an SP. Some very advanced cases allow one IdP to be a relying party to another IdP.
    • Terms: Binding
      • A description of how a SAML message is attached to an underlying transport protocol, such as http or smtp.
      • For example: If the message is sent over HTTP what HTTP headers need to be set, what are the URL or form parameter names, etc.
    • Terms: Profile
      • A description of how to use SAML, over a specific binding, to accomplish a specific task (e.g. Single Signon) in an interoperable manner.
      • Profiles are the finest grained unit of interoperability within SAML.
    • Terms: Metadata
      • A description of the SAML features supported by a SAML entity. Most importantly this includes the URLs for communicating with an entity.
      • Shibboleth also uses this information to build technical trust between entities.
    • Lets take a Closer Look
      • http://www.switch.ch/aai/demo/2/medium.html
    • Installation
      • Unpack the Shibboleth distribution unzip -d /usr/local/src /opt/installfest/shibboleth-idp-2.0.0-bin.zip
      • Change to /usr/local/src/identityprovider
      • chmod +x ant.sh
      • Run the installation script; ./ant.sh
        • answer yes , this is a new install
        • use /opt/shibboleth-idp as your shib home directory
        • enter your hostname: idp # .example.com
        • enter password for your password
    • SHIB_HOME
      • /opt/shibboleth-idp should now contain:
        • bin
        • conf
        • credentials
        • lib
        • logs
        • metadata
        • war
      • The Shibboleth documentation refers to this directory as SHIB_HOME
    • SHIB_HOME/bin
      • Contains command line tools
      • aacli : Attribute authority command line interface allows you to simulate an attribute query/release
      • version : Provides the version of the IdP
    • SHIB_HOME/conf
      • The IdP’s configuration files.
      • We’ll cover most as we go through the course. We will not cover service.xml or internal.xml as these control advanced features.
    • SHIB_HOME/credentials
      • Credentials used by the IdP.
      • By default the IdP’s generated key (idp.key), cert (idp.crt) and a keystore (idp.jks) containing both are put here.
      • Good location to place things like trust anchor X.509 certs, cached CRLs, etc.
    • SHIB_HOME/lib
      • The libraries (jars) that make up the IdP.
      • These are copies of those that occur in the IdP WAR file and are only used by the command line tools.
    • SHIB_HOME/logs
      • Location of the Shibboleth log files.
      • process log : detailed description the IdP processing requests
      • access log : record of all the clients that connect to the idP
      • audit log : record of all information sent out from the IdP
    • SHIB_HOME/metadata
      • Default location where various metadata files are stored.
      • The IdP does not automatically load any metadata. Metadata read from a file, or stored backup copies of remote metadata are usually put in this directory.
    • SHIB_HOME/war
      • The location of the IdP WAR file created by the installer.
      • We point Tomcat to this file, instead of copying it to Tomcat, so that we don’t forget to copy new WARs if we rebuild the IdP (to add an extension, for example) or run into problems with Tomcat’s file caching mechanisms.
    • Metadata: Configuration
      • Metadata is loaded in to the IdP by metadata providers .
      • Metadata providers are configured in the relying-party.xml file
      • This file may only contain one top-level provider. By default the top level provider is a chaining provider that contains other metadata providers and uses them in the order defined.
    • Metadata: Provider Config
      • Metadata providers are configured using <MetadataProvider> element
      • Every metadata provider has a:
        • unique ID given by the id attribute
        • type given by the xsi:type attribute
      • Each type of metadata provider has its own set of configuration options
      • Metadata provider may have a single filter defined by <MetadataFilter>
    • Metadata: Filesystem Provider
      • The filesystem metadata provider reads a metadata file from the local filesystem.
      • Type attribute value:
        • FilesystemMetadataProvider
      • Configuration attribute:
        • metadataFile gives the path to the metadata file
    • Metadata: File-backed HTTP Provider
      • Loads metadata via HTTP and backs it up to a local file
      • Type attribute value:
        • FileBackedHTTPMetadataProvider
      • Configuration Attributes:
        • metadataURL : HTTP URL of metadata file
        • backingFile : location of the backup file
        • cacheDuration : max time between refreshes
      • Refreshes metadata automatically, no more cron jobs!
    • Metadata: Watchout
      • The chaining metadata provider looks up relying party information in its children in the order they are defined. If two child providers load different metadata for the same entity only the first description will ever be used by the IdP. No attempt to merge the data is made.
    • Metadata: UK Configuration
      • Define the provider
      • <MetadataProvider id=“ ukfederation ”
      • xsi:type=&quot;FileBackedHTTPMetadataProvider”
      • xmlns=&quot;urn:mace:shibboleth:2.0:metadata”
      • metadataURL=“ http://metadata.ukfederation.org.uk/ukfederation-metadata.xml ”
      • backingFile=” /opt/shibboleth-idp/metadata/ukfed.xml ”>
      • <!-- Filter for requiring and validating digital signature -->
      • <MetadataFilter xsi:type=&quot;SignatureValidation”
      • xmlns=&quot;urn:mace:shibboleth:2.0:metadata&quot;
      • trustEngineRef=&quot;shibboleth.SignatureTrustEngine&quot;
      • requireSignedMetadata=&quot;true&quot; />
      • </MetadataProvider>
    • Metadata: UK Configuration
      • Download UK Federation Certificate curl http://metadata.ukfederation.org.uk/ukfederation.pem > /opt/shibboleth-idp/credentials/ukfederation.pem
      • Add Certificate to shibboleth.SignatureTrustEngine trust engine
      • <security:TrustEngine
      • xsi:type=&quot;security:StaticExplicitKeySignature&quot;
      • id=&quot;shibboleth.SignatureTrustEngine&quot;>
      • <Credential xsi:type=&quot;X509Filesystem”
      • xmlns=&quot;urn:mace:shibboleth:2.0:security&quot;
      • id=” UKFederationTrustAnchor&quot; >
      • <Certificate>
      • /opt/shibboleth-idp/credentials/ukfederation.pem
      • </Certificate>
      • </Credential>
      • </security:TrustEngine>
    • Terms: Authentication Method
      • An identifier that a relying party may use to stipulate how authentication should be performed.
      • Authentication method identifiers correspond to a prescription of how authentication is done (even if the details are only in someone’s head).
    • Terms: Login Handler
      • An IdP component that correlates all supported authentication methods with currently configured authentication mechanisms.
      • A login handler may map more than one authentication method to the same authentication mechanism.
    • Terms: Session
      • State information about the user, currently active authentication methods, and services to which they are signed into.
      • A user’s IdP session is created the first time they authenticate but may outlive the lifetime of all authentication methods.
    • Login Handler: Configuration
      • Login handlers are configured in handler.xml
      • <LoginHandler> defines a login handler
      • Every login handler definition has a xsi:type attribute that defines the type of the handler.
      • Each type has its own set of configuration options.
      • Each <LoginHandler> must contain at least one <AuthenticationMethod> indicating what authentication method it provides
    • Login Handler: UsernamePassword
      • Login handler that prompts for a username/password and validates against a JAAS module (LDAP & Kerberos 5 currently supported)‏
      • Type attribute value: UsernamePassword
      • Configuration attributes:
        • jaasConfigurationLocation path to the JAAS configuration file
    • Login Handler: UsernamePassword
      • Edit the login.config
      • Uncomment the LDAP login modules
      • Configure it like this:
      • edu.vt.middleware.ldap.jaas.LdapLoginModule required
      • host=” ldap.example.org ”
      • base=&quot; ou=people,dc=example,dc=org &quot;
      • userField=&quot; uid &quot;;
    • Login Handler: UsernamePassword
      • Edit handler.xml
      • Comment out RemoteUser handler
      • Uncomment UsernamePassword handler
      • Add unspecified authentication method <AuthenticationMethod> urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified </AuthenticationMethod>
    • Login Handler: Authentication Duration
      • Each authentication mechanism supports an activity timeout
      • After this timeout expires the mechanism is considered inactive for that user.
      • If the user attempts to access a new service provider that requires that authentication mechanism they must re-authenticate.
      • It is configured by the authenticationDuration attribute on the <LoginHandler>
      • Its value is the number of minutes of inactivity and its default value is 30.
    • Forced Authentication
      • Only works with mechanisms that can re-authenticate a user.
      • RemoteUser does not support forced authentication.
      • The service provider will receive an error if the IdP can not support forced authentication
    • Terms: Authentication Mechanism
      • A concrete mechanism used to authenticate a user.
      • Shibboleth 2 currently supports REMOTE_USER, user/pass against LDAP & Kerberos, and IP address based mechanisms.
    • Attribute Resolution
    • Terms: Attribute
      • A piece of information about a user. Each attribute has a unique ID and has zero of more values.
      • Shibboleth attributes are protocol-agnostic data structures.
    • Terms: SAML Attribute
      • An attribute that is represented in SAML notation.
      • Shibboleth transforms attributes into SAML attributes by a process known as encoding.
    • Terms: Data Connector
      • A plugin that creates multiple attributes from information in data sources like LDAP and databases.
      • Shibboleth currently supports static, LDAP, relational database, computed, and stored ID data connectors.
    • Data Connection Configuration
      • Data connectors are configured in attribute-resolver.xml
      • <DataConnector> defines a data connector
      • Every data connector has a id attribute that uniquely identifies it.
      • Every data connector has a xsi:type attribute that defines the type of the handler.
      • Each type has its own set of configuration options.
    • Data Connector Configuration
      • Some connectors will need information collected by another plugin in order to work. This is represented by a <resolver:Dependency ref=“NAME” />
      • The dependency is declared before any other configuration elements.
      • The value of the ref attribute is the ID of the plugin upon which the connector depends.
    • Data Connector Failover
      • Data connectors may define failover connectors such that if the data connector fails the failover connector is invoked.
      • If more than one failover connector is defined they are tried in order until one succeeds.
      • They are defined using: <resolver:FailoverDataConnector ref=&quot; CONNECTOR_ID_1 &quot; />
    • Terms: Attribute Definition
      • A plugin that creates a single attribute by transforming other attributes and state information.
      • Shibboleth currently supports simple, scoping, regex, mapping, template, scripting, principal name, and principal authentication method attribute definitions.
    • Attribute Definition Configuration
      • Attribute definitions are configured in attribute-resolver.xml
      • <AttributeDefinition> defines a definition
      • Every definition has a id attribute that uniquely identifies it.
      • Every definition has a xsi:type attribute that defines the type of the handler.
      • Each type has its own set of configuration options.
    • Attribute Definition Configuration
      • Most definitions will need information collected by another plugin in order to work. This is represented by a <resolver:Dependency ref=“NAME” />
      • The dependency is declared before any other configuration elements.
      • The value of the ref attribute is the ID of the plugin upon which the definition depends.
    • Terms: Attribute Encoder
      • A plugin that converts an attribute into a protocol specific form, like a SAML attribute.
      • Attribute encoders are associated with an attribute through the attribute’s attribute definition.
    • Attribute Encoder Configuration
      • Attribute encoders are configured as children of an attribute definition.
      • <AttributteEncoder> defines an encoder
      • Every definition has a xsi:type attribute that defines the type of the handler.
      • Each type has its own set of configuration options.
    • Terms: Principal Connector
      • A plugin that converts a name identifier, provided by a relying party, into the internally used userid.
    • Terms: Attribute Resolver
      • A subsystem in Shibboleth responsible for fetching, transforming, and associating encoders with attributes.
      • Only attributes produced by attribute definitions leave the resolver and are available to other parts of the system.
    • More About Attribute Dependencies
      • Any resolver plugin may have any number of dependencies.
      • If more than one dependency provides the same attribute the dependant plugin operates on the effective union of values
      • Attribute definitions may be marked with a dependencyOnly=“true” attribute. This ensures the value is never released outside the resolver (and speeds up filtering a bit).
    • Some Examples – LDAP Connector
      • <resolver:DataConnector xsi:type=&quot;LDAPDirectory&quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:dc&quot; id=&quot; MyLDAP &quot; ldapURL=&quot; LDAP_URL &quot; baseDN=&quot; BASE_DN &quot; principal=&quot; PRINCIPAL_NAME &quot; principalCredential=&quot; PRINCIPAL_CREDENTIAL &quot;>
      • <FilterTemplate>
      • <![CDATA[
      • ( uid =${requestContext.principalName})‏
      • ]]>
      • </FilterTemplate>
      • <ReturnAttributes> x y z </ReturnAttributes>
    • Some examples – Static Connector
      • <resolver:DataConnector id=&quot; staticEntitlements &quot; xsi:type=&quot;dc:Static&quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:dc&quot;>
      • <Attribute id=&quot; eduPersonEntitlement &quot;>
      • <Value> urn:mace:dir:entitlement:common-lib-terms </Value>
      • </Attribute>
      • </resolver:DataConnector>
    • Example – Simple Directory Lookup of epe
      • <resolver:AttributeDefinition id=&quot; eduPersonEntitlement &quot; xsi:type=&quot; Simple &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; sourceAttributeID=&quot; shibentitlement &quot;>
      • <resolver:Dependency ref=&quot; myLDAP &quot; />
      • <!-- Attribute encoders -->
      • </resolver:AttributeDefinition>
    • Example – Attribute Encoders
      • <resolver:AttributeEncoder xsi:type=&quot; SAML1String&quot; xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot; name=&quot; urn:mace:dir:attribute -def:eduPersonEntitlement &quot; />
      • <resolver:AttributeEncoder xsi:type=&quot; SAML2String&quot; xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot; name=&quot; urn:oid:1.3.6.1.4.1.5923.1.1.1.7 &quot; friendlyName=&quot; eduPersonEntitlement &quot; />
    • Some examples – Static entitlements
      • <resolver:AttributeDefinition id=&quot; eduPersonEntitlement &quot; xsi:type=&quot; Simple &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; sourceAttributeID=&quot; shibentitlement &quot;>
      • <resolver:Dependency ref=&quot; staticEntitlements &quot; />
      • <!-- Attribute Encoders -->
      • </resolver:AttributeDefinition>
    • Example – Computing epe from group membership
      • <resolver:AttributeDefinition xsi:type=&quot;Script&quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; id=&quot; eduPersonEntitlement &quot;>
      • <Dependency ref=&quot;MyLDAP&quot; />
      • <Script>
      • <![CDATA[ // Script here
      • ]]>
      • </Script>
      • </resolver:AttributeDefinition>
    • Example – Continued
      • <![CDATA[ importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider); epe = new BasicAttribute(&quot;eduPersonEntitlement&quot;); for (i = 0; i<isMemberOf.getValues().size(); i++ { if (isMemberOf.getValues().get(i)).equals(&quot;STF&quot;){ epe.getValues().add(&quot;member&quot;); epe.getValues().add(&quot;staff&quot;);
      • }
      • }
      • ]]>
    • Example – eptid computed
      • <resolver:AttributeDefinition xsi:type=&quot; Scoped &quot; id=&quot; eduPersonTargetedID &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; scope=&quot; example.org &quot; sourceAttributeID=&quot; computedID &quot;>
      • <resolver:Dependency ref=&quot; computedIDConnector &quot; />
      • </resolver:AttributeDefinition>
      • <resolver:DataConnector xsi:type=&quot; ComputedId &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:dc&quot; id=&quot; computedIDConnector &quot; generatedAttributeID=&quot; computedID &quot; sourceAttributeID=&quot; uid &quot; salt=&quot; your random string here &quot;>
      • <resolver:Dependency ref=&quot;myLDAP&quot; />
      • </resolver:DataConnector>
    • Example – eptid stored
      • <resolver:AttributeDefinition xsi:type=&quot; Scoped &quot; id=&quot; eduPersonTargetedID &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; scope=&quot; example.org &quot; sourceAttributeID=&quot; storedID &quot;>
      • <resolver:Dependency ref=&quot; storedIDConnector &quot; />
      • </resolver:AttributeDefinition>
    • Example - Continued
      • <resolver:DataConnector xsi:type=&quot; StoredId &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:dc&quot; id=&quot; storedIDConnector &quot; generatedAttributeID=&quot; storedID &quot; sourceAttributeID=&quot; uid &quot; salt=&quot; ThisIsRandomText &quot;> <resolver:Dependency ref=&quot;MyLDAP&quot; /> <ApplicationManagedConnection jdbcDriver=&quot;DRIVER_CLASS&quot;
      • jdbcURL=&quot;DATABASE_URL&quot; jdbcUserName=&quot;DATABASE_USER&quot; jdbcPassword=&quot;DATABASE_USER_PASSWORD&quot; />
      • <!-- Remember to JDBC driver in correct place -->
      • </resolver:DataConnector>
    • Example – Continued
      • Database created with:
      • CREATE TABLE shibpid (
      • localEntity VARCHAR NOT NULL,
      • peerEntity VARCHAR NOT NULL,
      • principalName VARCHAR NOT NULL,
      • localId VARCHAR NOT NULL,
      • persistentId VARCHAR NOT NULL,
      • peerProvidedId VARCHAR NULL,
      • creationDate TIMESTAMP NOT NULL,
      • deactivationDate TIMESTAMP NULL
      • )‏
    • Example – adding scope
      • <resolver:AttributeDefinition id=&quot; eduPersonPrincipalName &quot; xsi:type=&quot; Scoped &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; scope=&quot; example.org &quot; sourceAttributeID=&quot; uid &quot;>
      • <resolver:Dependency ref=&quot;myLDAP&quot; />
      • </resolver:AttributeDefinition>
    • Example - prescoped
      • <resolver:AttributeDefinition id=&quot; eduPersonPrincipalName &quot; xsi:type=&quot; Precoped &quot; xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot; scope=&quot; example.org &quot; sourceAttributeID=&quot; shibeppn &quot;>
      • <resolver:Dependency ref=&quot;myLDAP&quot; />
      • </resolver:AttributeDefinition>
    • Attribute Filtering
    • Terms: Attribute Filter Policy
      • A policy containing a trigger, that indicates if the policy is active, and a set of attribute value filters.
    • Attribute Filter Policy Configuration
      • Attribute filters are defined in attribute-filter.xml
      • Attribute filter policies are declared with <AttributeFilterPolicy>
      • Every filter policy has a single id attribute that provides a unique name for the policy.
    • Terms: Policy Requirement Rule
      • A specific requirement that must be met in order for an attribute filter policy to in effect.
      • An attribute filter policy may only have one requirement rule but some rules allow child rules to be declared and combined.
    • Policy Requirement Rule Configuration
      • <PolicyRequirementRule> defines a requirement rule.
      • Every rule has a xsi:type attribute that defines its type.
      • Each type has its own set of configuration options.
      • Every attribute filter policy must have one, and only one, policy requirement rule
    • Terms: Attribute Rule
      • A rule, specific to an attribute, that determines which values are released to a relying party.
      • An attribute filter policy may have any number of attribute rules.
    • Attribute Rule Configuration
      • A rule representing the set of values released to a relying party.
      • <AttributeRule> defines a rule.
      • Every rule has an attributeID attribute that identifies the attribute, by ID, to which the rule applies
    • Terms: Permit Value Rule
      • A rule that determines if an attribute value is permitted to be released to a relying party.
    • Permit Value Rule Configuration
      • A rule that signifies a value should be released to the requester.
      • <PermitValueRule> defines a rule.
      • Every rule has a xsi:type attribute that defines its type.
      • Each type has its own set of configuration options.
    • Attribute Filtering Gotchyas
      • Only those values explicitly permitted are ever released
      • There is no way to expressly deny the release of an attributes so be careful how your attribute filter policies overlap (deny value rules will be in 2.1)‏
      • Rules that operate on an attributes’ values will not take into consideration value scopes.
    • Example – Release eptid & eppn to anyone
      • <AttributeFilterPolicy id=&quot; releaseToAnyone &quot;>
      • <PolicyRequirementRule xsi:type=&quot;basic:ANY&quot; />
      • <AttributeRule attributeID=&quot; eduPersonTargetedID &quot;>
      • <PermitValueRule xsi:type=&quot; basic:ANY &quot; />
      • </AttributeRule>
      • <AttributeRule attributeID=&quot; eduPe...cipalName &quot;>
      • <PermitValueRule xsi:type=&quot; basic:ANY &quot; />
      • </AttributeRule>
      • </AttributeFilterPolicy>
    • Example – Release eppn to specific SPs
      • <AttributeFilterPolicy id=&quot; releaseEPPN &quot;> <PolicyRequirementRule xsi:type=&quot;basic:OR&quot;> <basic:Rule xsi:type=&quot; saml:AttributeRequesterString &quot; value=&quot; https://sdauth.sciencedirect.com/sp &quot; />
      • <basic:Rule xsi:type=&quot; saml:AttributeRequesterString &quot; value=&quot; urn:mace:athens:somesp &quot; />
      • </PolicyRequirementRule>
      • <AttributeRule attributeID=&quot; eduPer...cipalName &quot;>
      • <PermitValueRule xsi:type=&quot; basic:ANY &quot; />
      • </AttributeRule>
      • </AttributeFilterPolicy>
    • Example – Release only allowed epa values
      • <AttributeFilterPolicy>
      • <PolicyRequirementRule xsi:type=&quot; basic:ANY &quot; /> <AttributeRule attributeID=&quot; eduPersonAffiliation &quot;>
      • <PermitValueRule xsi:type=&quot; basic:OR &quot;>
      • <basic:Rule xsi:type=&quot; basic:AttributeValueString &quot;
      • value=&quot; member &quot; ignoreCase=&quot; true &quot; />
      • <basic:Rule xsi:type=&quot; basic:AttributeValueString &quot;
      • value=&quot; staff &quot; ignoreCase=&quot; true &quot; />
      • <!-- etc. -->
      • </PermitValueRule>
      • </AttributeRule>
      • </AttributeFilterPolicy>
    • Example – Release eppn to specific entitygroups
      • <AttributeFilterPolicy id=&quot; releaseEPPN &quot;> <PolicyRequirementRule xsi:type=&quot;basic:OR&quot;> <basic:Rule xsi:type=&quot; saml:AttributeRequesterInEntityGroup &quot; value=&quot; https://ukfederation.org.uk &quot; />
      • <basic:Rule xsi:type=&quot; saml:AttributeRequesterInEntityGroup &quot; value=&quot; urn:mace:athens &quot; />
      • </PolicyRequirementRule>
      • <AttributeRule attributeID=&quot; eduPer...cipalName &quot;>
      • <PermitValueRule xsi:type=&quot; basic:ANY &quot; />
      • </AttributeRule>
      • </AttributeFilterPolicy>
    • Example – Release eppn to all Sps except...
      • <AttributeFilterPolicy id=&quot; releaseEPPN &quot;>
      • <PolicyRequirementRule xsi:type=&quot; basic:NOT &quot;>
      • <basic:Rule xsi:type=&quot; basic:OR &quot;>
      • <basic:Rule xsi:type=&quot; saml:AttributeRequesterString &quot; value=&quot; http://sdauth.sciencedirect.com/sp &quot; />
      • <basic:Rule xsi:type=&quot; saml:AttributeRequesterString &quot; value=&quot; urn:mace:athens:somesp &quot; />
      • </basic:Rule>
      • </PolicyRequirementRule>
      • <AttributeRule attributeID=&quot; eduPersonPrincipalName &quot;>
      • <PermitValueRule xsi:type=&quot; basic:ANY &quot; />
      • </AttributeRule>
      • </AttributeFilterPolicy>
    • Example – Release epe if AuthN method is x or y & SP is z...
      • <PolicyRequirementRule xsi:type=&quot; basic:AND &quot;>
      • <basic:Rule xsi:type=&quot; basic:OR &quot;>
      • <basic:Rule xsi:type=&quot; ...AuthenticationMethodString &quot; value=&quot; some-string-for-iris-scan &quot; />
      • <basic:Rule xsi:type=&quot; ...AuthenticationMethodString &quot; value=&quot; some-string-for-fingerprint-reader &quot; />
      • </basic:Rule>
      • <basic:Rule xsi:type=&quot; ..AttributeRequesterStrin g&quot; value=&quot; https://myfinanceapp.example.org/sp &quot; />
      • </basic:Rule>
      • </PolicyRequirementRule>