Idp v3 fresh install but reuse old certs and metadata etc

[Cantor, Scott]

On 6/10/15, 6:43 PM, "users on behalf of C G" <users-bounces at shibboleth.net on behalf of ci_98yr at yahoo.com> wrote:

>Yes,  upgrade from existing  v2 to v3 would have been a choice, but we 
>Had some integration work and to make sure all is working with v3 with integration/customization.

I still think that's the easiest answer, you're just going to end up duplicating all the steps the upgrade would do, mostly. Any customization is probably 90% authentication, which isn't upgraded anyway, so that's just copying files back over.

It's easier to upgrade and then replace/update the pieces you don't plan to reuse than try and reverse engineer it.

>Have an old v2 idp working. Have a few SPs external configured and pointing to this v2 idp.
>We have a fresh install and customized v3. Would like to reuse v2 certs, metadata and anything that can 
>Be reused so we have no change on those SPs. 
>
>Can someone point me to step by step on reuse of major elements from v2 for v3?

I guess review the upgrade topic and the steps involved to "modernize" an upgraded configuration?

I don't know exactly what pieces you're trying to keep. Your old relying-party file is your metadata file, and for that matter it's also your relying-party file unless you plan to convert it, which would amount to *not* reusing it, so depends on what you're trying to reuse.

Reusing keypairs should be self-evident, just replace/rename them. There is/was no encryption key in V2, so you can't be using one and there's no point in trying to avoid using a new one.

All of your attribute config is the same/reusable. Unless you don't want to reuse it, so again, depends on the desired outcome.

If you're fundamentally asking what the upgrade process does, basically:

- it backs up all the conf files to conf.v2
- it creates a new conf tree
- it copies the old relying-party.xml file in and to metadata-providers.xml
- it copies old attribute-resolver.xml and attribute-filter.xml
- it skips the public key generation steps (but not the secret key step)
- it sets a property or two, principally idp.service.relyingparty.resources = shibboleth.LegacyRelyingPartyResolverResources (enables the backward compat support)

I'm probably forgetting something, but that's the bulk of it. What you end up with isn't really super far from a fresh install with the exception of the files above.

I think it also does a few advanced things to pre-populate some LDAP settings in ldap.properties.

-- Scott