<div dir="ltr"><div>AD FS doesn't need keyname. But if it receives keyname it must match cert Subject. I am trying to see what AD FS accepts/rejects by playing around with various formats of element values in the signature.</div>
<div> </div><div>I'll give this a shot and see how it goes.</div><div> </div><div>Thanks </div><div> </div><div>Mat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 April 2013 21:00, Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 4/19/13 2:21 PM, Matheesha Weerasinghe wrote<br>
<div class="im"><br>
><br>
> My interest here is to test some interoperability stuff with AD FS 2.0. Its for use in a lab<br>
> environment.<br>
<br>
</div>Does ADFS really require a key name like that? I think other people have interoped with ADFS and<br>
didn't have that requirement.<br>
<div class="im"><br>
<br>
<br>
><br>
> So if you could give some instructions, I have a java developer who I can get the help of to<br>
> follow your instructions and try implement it here.<br>
<br>
<br>
</div>I forgot that I already had a little project that illustrates close to the same thing for<br>
customizing some XML Encryption behavior, so I just added this to it and threw it in Subversion. You<br>
can checkout from the Subversion URL below [1]. Basically check out and do an 'mvn package'. The<br>
install docs are in doc/INSTALL.txt.<br>
<br>
The extension is just hardcoded to enable the emitKeyNames flag on the KeyInfoGenerators. As Scott<br>
mentioned, you'd need to then populate the KeyName element on the Credential config in the IdP.<br>
This extension should then let those get expressed if they are present.<br>
<br>
You could also easily add some code in the config bean to play around with some of the other<br>
properties on the generators to emit KeyNames from the DN, CN and subject alt name cert info, as<br>
well as any of the other generator properties. See the OpenSAML Javadocs for details on all of<br>
those options.<br>
<br>
If there were enough interest to justify, the extension's config bean could be expanded to its<br>
logical conclusion and expose property setters which would allow declarative config of most of the<br>
OpenSAML global security configuration right in the internal.xml.<br>
<br>
--Brent<br>
<br>
<br>
[1]<br>
<a href="https://svn.middleware.georgetown.edu/putmanb/shibboleth-idp-ext-opensaml-custom-security-config/trunk/" target="_blank">https://svn.middleware.georgetown.edu/putmanb/shibboleth-idp-ext-opensaml-custom-security-config/trunk/</a><br>
<div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>