[prev in list] [next in list] [prev in thread] [next in thread]
List: shibboleth-users
Subject: Re: Including keyName in keyInfo
From: Matheesha Weerasinghe <matheesha () gmail ! com>
Date: 2013-04-21 2:13:14
Message-ID: CAABjJgFwwjVEHNFBwbkmuezf2EqkvskW5vx_oQvAhd0FwKk05A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
I'll give this a shot and see how it goes.
Thanks
Mat
On 19 April 2013 21:00, Brent Putman <putmanb@georgetown.edu> wrote:
>
> On 4/19/13 2:21 PM, Matheesha Weerasinghe wrote
>
> >
> > My interest here is to test some interoperability stuff with AD FS 2.0.
> Its for use in a lab
> > environment.
>
> Does ADFS really require a key name like that? I think other people have
> interoped with ADFS and
> didn't have that requirement.
>
>
>
> >
> > So if you could give some instructions, I have a java developer who I
> can get the help of to
> > follow your instructions and try implement it here.
>
>
> I forgot that I already had a little project that illustrates close to the
> same thing for
> customizing some XML Encryption behavior, so I just added this to it and
> threw it in Subversion. You
> can checkout from the Subversion URL below [1]. Basically check out and
> do an 'mvn package'. The
> install docs are in doc/INSTALL.txt.
>
> The extension is just hardcoded to enable the emitKeyNames flag on the
> KeyInfoGenerators. As Scott
> mentioned, you'd need to then populate the KeyName element on the
> Credential config in the IdP.
> This extension should then let those get expressed if they are present.
>
> You could also easily add some code in the config bean to play around with
> some of the other
> properties on the generators to emit KeyNames from the DN, CN and subject
> alt name cert info, as
> well as any of the other generator properties. See the OpenSAML Javadocs
> for details on all of
> those options.
>
> If there were enough interest to justify, the extension's config bean
> could be expanded to its
> logical conclusion and expose property setters which would allow
> declarative config of most of the
> OpenSAML global security configuration right in the internal.xml.
>
> --Brent
>
>
> [1]
>
> https://svn.middleware.georgetown.edu/putmanb/shibboleth-idp-ext-opensaml-custom-security-config/trunk/
> --
> To unsubscribe from this list send an email to
> users-unsubscribe@shibboleth.net
>
[Attachment #5 (text/html)]
<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>
--
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic