Is there a checklist for the metadata file?

[Joe Edwards]

Yes, I am working for the UW Medical Center, not UW ITS.
I know the ITS guys and have discussed SSO with them, a lot.

Our pubcookie server is independent of the UW ITS pubcookie
server. And our IDP server will have to be separate too.
HIPAA requirements for medical record access require that we
have strict control of our authentication process, including
the user authentication database - our interpretation.

I would use the existing UW ITS pubcookie and shibboleth servers,
if I could. When I moved us to pubcookie, I initially pointed
at the UW ITS pubcookie server, but that did not work out.

I would prefer to keep my idp server as an enterprise operation.
And not include it in a federation. That sounds like an option.
I handle the pubcookie server clients manually now. Not much
effort. And it sounds like I can manage the IDP and SPs the
same way. I can host the IDP metadata and register the SPs.
I am in a controlled environment and have a limited number
of SSO clients.

Thanks for helping me to work through this.

Joe Edwards
UWMC, ITS, Senior Computer Specialist


On Mon, 30 Mar 2015, Cantor, Scott wrote:
> On 3/29/15, 9:35 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>> On Sun, Mar 29, 2015 at 8:54 PM, Joe Edwards <joee at uw.edu> wrote:
>>>
>>> Now, to learn enough to get our future production shibboleth
>>> server joined to a federation.
>>
>> Your organization already has a production IdP in the InCommon
>> Federation (and has had one for a very, very long time).
>
> I assume he's at a separate campus, med center, etc.
>
>> That's what I mean...the metadata you publish *is* your IdP, not the
>> infrastructure underneath.
>
> Or another way to say it, the metadata represents the "public" view of 
> the system. The internals can be different, either because something's 
> being undeployed or something's going to be deployed and needs to be 
> published ahead of time.
>
> -- Scott
>