documentation regarding ApplicationOverrides and metadata generator

csross cross at hccs.com
Tue Aug 21 09:18:27 EDT 2012


Thank you.

 

On 8/20/12 6:49 PM, "csross" <[hidden email]> wrote: 

>I have multiple v2.4.3 SPs and each defined in an ApplicationOverride
and 
>vhost and I am able to bring up metadata for each SP.  The
documentation 
>indicates this below but it doesn't say what will be wrong or missing. 

Lots of advanced features, policy flags, keys during credential
rollovers 
(you CANNOT safely migrate keys using only generated metadata), contact 
information, new extensions. Many, many things. None of that has
anything 
to do with overrides particularly. 

The point about overrides is that by definition a request to a handler
is 
talking to one application, period, and so by definition you can't be 
incorporating input coming from the others, whatever that input is.
There 
is no way to answer the specific question unless the purpose of the 
overrides is made clear. 

>One of the SPs was originally the only one (v2.2) so it was defined as
the 
>ApplicationDefault and the metadata  looks very similar.  After
upgrading 
>and switching to ApplicationOverrides, I generated the metadata in the 
>same 
>way (https://site.site.com/Shibboleth.sso/Metadata) and sent it to the
IDP 
>admin.  The IDP is shibboleth and the admin said it looked fine.  The
site 
>is working too. 

That's usually a sign the override isn't/wasn't needed. 

>NOTE:  In the metadata when 1 SP as ApplicationDefault was used, the
X509 
>certificate is different, there is an extra certificate
md:KeyDescriptor 
>use="signing" and there are these lines 

That's not because of the overrides, that's a question of configuration 
differences and version differences. You do not need and should not 
advertise NameID management endpoints. If you don't know what they do,
you 
don't have them. That goes for essentially everything in the metadata. 

As a starting point, you should be able to understand the differences.
If 
you can't do that, I would strongly urge that you read the
specification. 
There's no other advice I can give but to do that. There's no book to 
read, or I would give you a link to it. 

-- Scott 

-- 
To unsubscribe from this list send an email to [hidden email] 



________________________________

If you reply to this email, your message will be added to the discussion
below:

http://shibboleth.1660669.n2.nabble.com/documentation-regarding-Applicat
ionOverrides-and-metadata-generator-tp7581403p7581404.html 

To unsubscribe from documentation regarding ApplicationOverrides and
metadata generator, click here
<http://shibboleth.1660669.n2.nabble.com/template/NamlServlet.jtp?macro=
unsubscribe_by_code&node=7581403&code=Y3Jvc3NAaGNjcy5jb218NzU4MTQwM3wtND
I4NjA4MTk0> .
NAML
<http://shibboleth.1660669.n2.nabble.com/template/NamlServlet.jtp?macro=
macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.name
spaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.vi
ew.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3A
email.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nab
ble%3Aemail.naml>  





--
View this message in context: http://shibboleth.1660669.n2.nabble.com/documentation-regarding-ApplicationOverrides-and-metadata-generator-tp7581403p7581406.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120821/1b3261d5/attachment.html 


More information about the users mailing list