[Shib-Users] experimenting with uApprove, metadata filter
Steven Carmody
filter, trying to see if I can construct a demo for the IC session at I2MM.
Here at Brown, our Production and QA IDPs already include uApprove,
configured to use a DB. Unfortunately, they're running v2.1.5. But, I'm
hoping that the shortest path will be to use them.
My first attempt is to add Scott's new filter to a QA IDP instance, and
see if that can be made to work. I certainly understand there are no
guarantees here. But, seemed worth a try....
Things run without a problem (mostly -- that will be the next thread).
unfortunately, tho, the new filter isn't releasing anything.
Down below I have:
-- 2 sets of lines from the log file. The first indicates -- I think --
that the plugin found the appropriate metadata entry, and then found a
matching AttributeConsumingService element. The worry is the index=0
(the value in the metadata is 1). Unless 0 means it didn't find
anything.... note that I'm loading a local file containing the metadata
for SP, and then loading the metadata for the campus (which contains an
older entry for the same SP; in the past, this has worked OK.
the second set of lines were produced during the filtering phase and
indicate that EPPN was NOT released.
-- the next block is the AttributeConsumingService element from the
metadata for the SP.
-- the third block is the relevant Filter Policy.....
Any and all suggestions appreciated.
14:01:41.592 - DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.MetadataAccess:31] - RelyingParty info
for entityId https://stc-test2.cis.brown.edu/shibboleth-sp
14:01:41.592 - DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.MetadataAccess:39] - entityDescriptor
org.opensaml.saml2.metadata.impl.EntityDescriptorImpl@26f6807c
14:01:41.593 - DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.MetadataAccess:57] - SPSSODescriptor
for protocol urn:oasis:names:tc:SAML:2.0:protocol is
org.opensaml.saml2.metadata.impl.SPSSODescriptorImpl@1b5b0282
14:01:41.593 - DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.MetadataAccess:71] -
AttributeConsumingService with index 0 found
14:01:41.877 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156]
- Processing permit value rule for attribute eduPersonPrincipalName for
principal s...@BROWN.EDU
14:01:41.877 - DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
- attribute requester's metadata role does not contain attribute
requirements
<md:AttributeConsumingService index="1">
<md:ServiceName xml:lang="en">Sample Service</md:ServiceName>
<md:ServiceDescription xml:lang="en">An example service that
requires a human-readable identifier and optional name and e-mail
address.</md:ServiceDescription>
<md:RequestedAttribute FriendlyName="eduPersonPrincipalName"
Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"
isRequired="true"/>
<md:RequestedAttribute FriendlyName="mail"
Name="urn:mace:dir:attribute-def:mail"
NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"/>
<md:RequestedAttribute FriendlyName="displayName"
Name="urn:mace:dir:attribute-def:displayName"
NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"/>
</md:AttributeConsumingService>
<AttributeFilterPolicy id="releaseeduPersonPrincipalNameToCampus">
<PolicyRequirementRule xsi:type="basic:ANY" />
<AttributeRule attributeID="eduPersonPrincipalName">
<PermitValueRule xsi:type="ua:AttributeInMetadata"
onlyIfRequired="false" />
</AttributeRule>
Scott Cantor
>
> -- 2 sets of lines from the log file. The first indicates -- I think --
> that the plugin found the appropriate metadata entry, and then found a
> matching AttributeConsumingService element. The worry is the index=0
> (the value in the metadata is 1).
Different plugin. I think uApprove looks at those elements as well, but I
don't know what the index=0 signifies.
> Unless 0 means it didn't find
> anything.... note that I'm loading a local file containing the metadata
> for SP, and then loading the metadata for the campus (which contains an
> older entry for the same SP; in the past, this has worked OK.
I wouldn't ever rely on that working if there's any doubt.
> 14:01:41.877 - DEBUG
> [ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
> - attribute requester's metadata role does not contain attribute
> requirements
I believe that indicates the metadata it's seeing does NOT have the info in
it.
It's also worth noting that the mechanism is mostly designed to be SAML 2
only, but the actual lookup for matching attributes is protocol-specific. If
the names in the metadata are used only by SAML 1 encoders in the IdP, they
won't match if the incoming request is SAML 2 and vice versa.
-- Scott
Scott Cantor
> > [ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
> > - attribute requester's metadata role does not contain attribute
> > requirements
>
> I believe that indicates the metadata it's seeing does NOT have the info
in
> it.
I found the code Halm released, and that's definitely the meaning of that
message, no such information in the metadata for the SP.
> It's also worth noting that the mechanism is mostly designed to be SAML 2
> only, but the actual lookup for matching attributes is protocol-specific.
If
> the names in the metadata are used only by SAML 1 encoders in the IdP,
they
> won't match if the incoming request is SAML 2 and vice versa.
That part's wrong though, I started it that way and then abandoned it in
favor of just looking for a matching Name/NameFormat/AttributeNamespace in
any encoders regardless of SAML version.
-- Scott
Chad La Joie
In a real deployment you'd probably want to make sure you put both the
SAML1 and SAML2 attribute names in there. We haven't implemented
support for requested attributes in attribute queries but when we do
it'll be looking for the SAML 2 names only.
--
Chad La Joie
http://itumi.biz
trusted identities, delivered
Scott Cantor
> SAML1 and SAML2 attribute names in there. We haven't implemented
> support for requested attributes in attribute queries but when we do
> it'll be looking for the SAML 2 names only.
It's a pretty big rathole in practice, and my sense is that we want to steer
the idea of dynamic release in the direction of SAML 2 only. Doing both
versions makes it essentially impossible to even think about labeling things
"required", for whatever that's worth anyway.
-- Scott
Steven Carmody
>
>> 14:01:41.877 - DEBUG
>> [ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
>> - attribute requester's metadata role does not contain attribute
>> requirements
>
> I believe that indicates the metadata it's seeing does NOT have the info in
> it.
>
> It's also worth noting that the mechanism is mostly designed to be SAML 2
> only, but the actual lookup for matching attributes is protocol-specific. If
> the names in the metadata are used only by SAML 1 encoders in the IdP, they
> won't match if the incoming request is SAML 2 and vice versa.
>
that looks like it might be the current problem... the metadata I
copy/pasted contains a SAML 1 name, but I'm using SAML 2 as the protocol...
one more question, tho... here's the element in my metadata:
<md:RequestedAttribute FriendlyName="eduPersonPrincipalName"
Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"
isRequired="true"/>
I'm guessing I should change the NameFormat value... but other than
changing the 1.0 to 2.0 ... does anything else need to change ?
Chad La Joie
SAML 2 only.
--
Scott Cantor
> copy/pasted contains a SAML 1 name, but I'm using SAML 2 as the
protocol...
It's not (see my correction). Your metadata has no attribute information in
it.
> one more question, tho... here's the element in my metadata:
>
> <md:RequestedAttribute FriendlyName="eduPersonPrincipalName"
> Name="urn:mace:dir:attribute-def:eduPersonPrincipalName"
> NameFormat="urn:mace:shibboleth:1.0:attributeNamespace:uri"
> isRequired="true"/>
>
> I'm guessing I should change the NameFormat value... but other than
> changing the 1.0 to 2.0 ... does anything else need to change ?
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-
200804.pdf
<md:RequestedAttribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
FriendlyName="eduPersonPrincipalName"/>
-- Scott
Scott Cantor
> SAML 2 only.
It's worth an option at minimum I would say.
-- Scott
Chad La Joie
flag and people really wanted to be able to use this with SAML 1 then
they could just split their entity descriptor and give it to two SP
roles, one with a SAML1 protocol support enumeration and one with a SAML
2 one. Then adjust the attribute requirements as appropriate.
That seems like a mess though.
--
Scott Cantor
> flag and people really wanted to be able to use this with SAML 1 then
> they could just split their entity descriptor and give it to two SP
> roles, one with a SAML1 protocol support enumeration and one with a SAML
> 2 one. Then adjust the attribute requirements as appropriate.
>
> That seems like a mess though.
There's no particular justification for interpreting the attribute
requirements in a Shibboleth SSO request anyway. There is no SAML 1 request,
and there's no way in Shibboleth requests to indicate that you want a
particular AttributeConsumingService, so I think it's just cleaner all
around to make a clean break.
-- Scott
Chad La Joie
work (for the metadata-resident attributes). I'm certainly not
advocating such an approach.
--
Steven Carmody
>
> <md:RequestedAttribute
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> FriendlyName="eduPersonPrincipalName"/>
>
I removed the loading of the campus metadata; this IDP is now loading
metadata for only my test SP.
I changed that metadata to include your suggestion from above.
Unfortunately, I'm still getting the same error:
DEBUG
[ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
- attribute requester's metadata role does not contain attribute
requirements
are there other potential mismatches that could result in that message ?
Scott Cantor
>
> Unfortunately, I'm still getting the same error:
>
> DEBUG
> [ch.SWITCH.aai.uApprove.idpplugin.mf.AttributeInMetadataMatchFunctor:99]
> - attribute requester's metadata role does not contain attribute
> requirements
>
> are there other potential mismatches that could result in that message ?
The error is logged right at the beginning of the function. It actually
means the role descriptor it's getting is not that of an SP.
// Check for SP role.
RoleDescriptor role =
filterContext.getAttributeRequestContext().getPeerEntityRoleMetadata();
if (!(role instanceof SPSSODescriptor)) {
log.debug("attribute requester's metadata role does not contain
attribute requirements");
return false;
}
It's a sanity check, basically. Somebody like Chad would have to comment on
why a cast like that might fail if the role actually is of the correct type,
but this looks like a build/environment issue of some kind.
I don't think it's possible for the peer role to be of any other kind given
the IdP's current assumptions?
-- Scott
Chad La Joie
On 10/19/10 4:06 PM, Scott Cantor wrote:
> It's a sanity check, basically. Somebody like Chad would have to comment on
> why a cast like that might fail if the role actually is of the correct type,
> but this looks like a build/environment issue of some kind.
Well, if there was an attempt to cast it it would fail.
> I don't think it's possible for the peer role to be of any other kind given
> the IdP's current assumptions?
It's hard to say since there isn't a complete log of what is going on.
I have no idea what type of request is being processed.
Scott Cantor
> > It's a sanity check, basically. Somebody like Chad would have to comment
> on
> > why a cast like that might fail if the role actually is of the correct
> type,
> > but this looks like a build/environment issue of some kind.
>
> Well, if there was an attempt to cast it it would fail.
I should have said "instanceof check", not cast (you can see the code
there).
> > I don't think it's possible for the peer role to be of any other kind
given
> > the IdP's current assumptions?
>
> It's hard to say since there isn't a complete log of what is going on.
> I have no idea what type of request is being processed.
Even if it's an attribute query, I was under the impression the peer role
would be SPSSODescriptor. I didn't think we implemented the extension roles
for queries.
Or alternatively maybe it's an anonymous SSO request...
-- Scott
Brent Putman
On 10/19/10 4:06 PM, Scott Cantor wrote:
>>
> The error is logged right at the beginning of the function. It actually
> means the role descriptor it's getting is not that of an SP.
>
> // Check for SP role.
> RoleDescriptor role =
> filterContext.getAttributeRequestContext().getPeerEntityRoleMetadata();
> if (!(role instanceof SPSSODescriptor)) {
> log.debug("attribute requester's metadata role does not contain
> attribute requirements");
> return false;
> }
>
> It's a sanity check, basically. Somebody like Chad would have to comment on
> why a cast like that might fail if the role actually is of the correct type,
> but this looks like a build/environment issue of some kind.
It can fail due to weird classloader issues, but as long as the plugin
and opensaml jars are in the war (so webapp classloader) and only in the
war, that wouldn't be a problem. Probably something simpler than that
here, though. The instanceof will eval to false if role is null, for
example, which could happen if the metadata wasn't injected into the
context yet at that point.
>
> I don't think it's possible for the peer role to be of any other kind given
> the IdP's current assumptions?
I implemented similar logic in the AttributeConsumingServiceSelector
that I wrote earlier this year. It also supports the
AttributeQueryDescriptor case, in addition to the SPSSODescriptor.
I might suggest using that component in your plugin, to avoid
duplicating logic. I wrote it for just this very case.
Chad La Joie
--
Scott Cantor
> and opensaml jars are in the war (so webapp classloader) and only in the
> war, that wouldn't be a problem. Probably something simpler than that
> here, though. The instanceof will eval to false if role is null, for
> example, which could happen if the metadata wasn't injected into the
> context yet at that point.
That should be "ok" in the sense that no metadata implies no possible set of
attributes. So one possibility is if the IdP is allowing anonymous RPs and
the metadata is incorrect in some way.
> > I don't think it's possible for the peer role to be of any other kind
given
> > the IdP's current assumptions?
>
> I implemented similar logic in the AttributeConsumingServiceSelector
> that I wrote earlier this year. It also supports the
> AttributeQueryDescriptor case, in addition to the SPSSODescriptor.
Ah, I didn't realize we had that. Does the profile handler code actually
inject that role for queries though? Or does it try for that role and back
off to SPSSODescriptor? Or...?
> I might suggest using that component in your plugin, to avoid
> duplicating logic. I wrote it for just this very case.
It's Halm's now. ;-)
-- Scott
Brent Putman
filter functor plugin. I understand why you want to resolve the
attribute Name and NameFormat in some automatic way, by drilling into
the encoders. It's "configuration by convention" or whatever. And where
that works, that is I guess a useful simplification. But I think in
this case, it tightly couples behavior in the filter to specific
assumptions about the resolver and encoder config. To me, the filter
plugin ought to (at least optionally) support explicitly stating the
Name and NameFormat in the functor itself (as well as the internal
attribute ID), so it's basically saying "release attribute 'foo' if
requested attribute Name=X and NameFormat=Y". If they are omitted, they
can fall back to the assumption of resolving the latter 2 by looking at
encoders, as you do know.
Stephen's issue highlights the very issue here: md:RequestedAttribute
isn't SAML 2 specific; for that matter, it's not even SAML specific.
You might want to state that an AttributeConsumingService needs or
requires an attribute over some protocol that isn't SAML (e.g. OpenID or
WS-Federation, etc). No, we're not doing those now, but this is a
functor, and IMHO should be more general in nature, at least have the
capability to do so. In those cases (or SAML 1), it's counter-intuitive
that you have to configure a SAML 2 encoder where that might in fact not
be want you want (maybe you really don't want *that* attribute
encoded/released over SAML 2).
BTW, is this filter plugin code up somewhere public? Wanted to take a
look at some point.
Brent Putman
> On If they are omitted, they
> can fall back to the assumption of resolving the latter 2 by looking at
> encoders, as you do know.
>
>
Should have said "as you do now". Although I guess you do also know
(now). :-)
Scott Cantor
> isn't SAML 2 specific; for that matter, it's not even SAML specific.
> You might want to state that an AttributeConsumingService needs or
> requires an attribute over some protocol that isn't SAML (e.g. OpenID or
> WS-Federation, etc).
Maybe. I suppose I'd have to think about the protocol implications, but such
a view would imply that if you *didn't* want a descriptor to apply to a
given protocol, you'd have to split the roles.
> No, we're not doing those now, but this is a
> functor, and IMHO should be more general in nature, at least have the
> capability to do so. In those cases (or SAML 1), it's counter-intuitive
> that you have to configure a SAML 2 encoder where that might in fact not
> be want you want (maybe you really don't want *that* attribute
> encoded/released over SAML 2).
I don't think we're suggesting that. Tying it to SAML 2 names would imply
tying it to SAML 2 requests only.
> BTW, is this filter plugin code up somewhere public? Wanted to take a
> look at some point.
The version released is in the uApprove source bundle:
https://www.switch.ch/aai/support/tools/uApprove.html#versions
For the benefit of people seeing the thread, it's 100%
experimental/prototypical/not-for-primetime. Mostly so we can have exactly
these discussions.
-- Scott
Chad La Joie
--
Brent Putman
On 10/19/10 4:25 PM, Scott Cantor wrote:
>>
>
> Ah, I didn't realize we had that. Does the profile handler code actually
> inject that role for queries though? Or does it try for that role and back
> off to SPSSODescriptor? Or...?
>
No, none of our current standard profile handlers make use of the
AttributeQueryDescriptorType extension at all, as far as I can tell. I
just implemented support for that in my selector in OpenSAML because the
library supports the metadata query extension, so seemed like it was
prudent to do.
In particular, the current profile handlers, even the SAML 1 and 2
AttributeQuery ones, are using the SPSSODescriptor role in the request
context.
Chad La Joie
incorrect metadata. What does the MetadataProvider section of your
relying party config file look like?
Steven Carmody
> There is nothing in your log file that suggests it's anything other than
> incorrect metadata. What does the MetadataProvider section of your
> relying party config file look like?
>
<MetadataProvider id="ShibbolethMetadata"
xsi:type="ChainingMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata">
<!-- load stc-test2 metadata first, to override entry in campus
metadata -->
<MetadataProvider id="STC2"
xsi:type="FilesystemMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata"
metadataFile="/opt/local/shibboleth-idp/metadata/stc-test2.cis.brown.edu-metadata.xml"
maintainExpiredMetadata="true">
</MetadataProvider>
</MetadataProvider>
Chad La Joie
within the chaining provider
--
Steven Carmody
> Thats not what is being loaded. Your log shows 2 metadata providers
> within the chaining provider
>
I can send you the latest log, which will have only one metadata
provider. Simplify... simplify.... (btw, the other one was the IC
metadata file.)
do you want that log file? It has the same error.