moving relying service to new domain

[David Bantz]

On Mon, 7 Jan 2013, at 18:45 , Christopher Bongaarts <cab at umn.edu> wrote:

> On 1/7/2013 3:38 PM, David Bantz wrote:
>> (1) Since the entityID is a name, not a location, seems that should be do-able without changing the IdP config - right?

> As already noted, yes, that's doable, but ensure the IdP gets updated metadata with endpoints corresponding to the new domain They can be added to the existing endpoints ahead of time to minimize coordination.
> -- 
> %%  Christopher A. Bongaarts   %%  cab at umn.edu          %%

Are  you saying I need to update portions of the SP metadata like

<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://service.olddomain.edu/Shibboleth.sso/Login"/>

and

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://service.olddomain.edu/Shibboleth.sso/SAML2/POST"/>

to reflect the new URL of the service

<init:RequestInitiator xmlns:init="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://service.new.domain.edu/Shibboleth.sso/Login"/>

and

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://service.new.domain.edu/Shibboleth.sso/SAML2/POST"/>

even though the entityID remains https://service.olddomain.edu/shibboleth ?

David Bantz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130108/f0c04f8d/attachment-0001.html