<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/27/18 12:34 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:641F99AD-E763-4077-9D50-2F416583AF12@osu.edu">
<pre wrap="">On 6/27/18, 12:13 PM, "dev on behalf of Tom Scavo" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfoftrscavo@gmail.com"><dev-bounces@shibboleth.net on behalf of trscavo@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I see. Unfortunately the getSPSSODescriptor method takes a protocol
string argument, so that looks like a dead end, at least for my
purposes.
</pre>
</blockquote>
</blockquote>
<br>
Well, it's less convenient for your purposes than a no-arg one, but
if all you practically care about is SAML 2 (and maybe SAML 1) then
you can certainly call that method with the relevant protocol URI
string(s) and achieve what you want.<br>
<br>
<blockquote type="cite"
cite="mid:641F99AD-E763-4077-9D50-2F416583AF12@osu.edu">
<pre wrap="">
I thought the Java API incuded subtype collection accessors, apparently not.</pre>
</blockquote>
<br>
It does have them (e.g. getSPSSODescriptor,
getAttributeAuthorityDescriptor, etc) but they all take a mandatory
desired protocol, and they return the single first matching one.
There are not no-arg variants that return the whole subtype
collection.<br>
<br>
I don't know why exactly that is. IIRC the metadata XMLObject code
was the very first that Chad wrote way back in 2005-ish, and so
probably wasn't anticipating this kind of use case. Usually when
you're looking for a specific descriptor type, you're doing in
context of generating or processing a request under a specific
protocol, so the existing accessors make sense for that. <br>
<br>
<blockquote type="cite"
cite="mid:641F99AD-E763-4077-9D50-2F416583AF12@osu.edu">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">There is a no-argument getRoleDescriptors() method but I don't know
how to map the resulting list of RoleDescriptor objects to the
corresponding list of local names. If I knew how to do that, I could
test if the list of local names contains "SPSSODescriptor".
</pre>
</blockquote>
</blockquote>
<br>
What you want to look at is the XMLObject interface. You can get
the role descriptor elements' QNames via getElementQName(). And if
necessary also the xsi:type QName via getSchemaType(). Then eval
the QNames however you want, either by testing for equality against
either a QName constant or one you have constructed (probably the
most correct) or just looking at the getLocalPart() of the QName.<br>
<br>
If using Java 8 at runtime, the most natural way to literally map
the descriptor list to a new list of type QName and then evaluate it
would be using lambdas. Then that whole test becomes a one-liner.
I'll list a couple of variants in pure Java below, but I don't know
what syntax modifications are necessary to work in JSR-223 scripting
using Javascript, etc. In fact I don't know for sure whether and
how lambdas work in scripts at all, maybe someone else does. I
imagine one way or another they do, though.<br>
<br>
Most compact, using method ref and default helper method:<br>
<br>
<tt> boolean found = entity.getRoleDescriptors().stream()</tt><tt><br>
</tt><tt> .map(RoleDescriptor::getElementQName)</tt><tt><br>
</tt><tt>
.anyMatch(Predicate.isEqual(SPSSODescriptor.DEFAULT_ELEMENT_NAME));</tt><tt><br>
</tt><br>
Less compact, using full Function and Predicate lambda expressions:<br>
<br>
<tt> boolean found = entity.getRoleDescriptors().stream()</tt><tt><br>
</tt><tt> .map(role -> {return
role.getElementQName();})</tt><tt><br>
</tt><tt> .anyMatch(name -> {return
SPSSODescriptor.DEFAULT_ELEMENT_NAME.equals(name);});</tt><tt><br>
</tt><br>
<br>
<br>
<blockquote type="cite"
cite="mid:641F99AD-E763-4077-9D50-2F416583AF12@osu.edu">
<pre wrap="">
Pretty sure it's just getLocalName() but refer to the javadocs I suppose, whatever is on XMLObject should expose the relevant information. Of course that only works for named child elements and not xsi:type'd extension children but that's good enough.
</pre>
</blockquote>
<br>
I don't think there is such a method on the interface XMLObject.
Maybe you're thinking of QName getLocalPart(). We might have a
static support method somewhere that returns that however, I don't
know.<br>
<br>
Or maybe you are thinking of the 'public static final String
DEFAULT_ELEMENT_LOCAL_NAME' members that we usually define. But that
is more of just a convention and not a contract.<br>
<br>
<br>
</body>
</html>