>>>>> "Kalle" == Kalle Happonen <[log in to unmask]> writes:

    Kalle> Hello all, We're starting to pilot Moonshot a bit more here
    Kalle> in Finland, and I'm trying to get more familiar with the
    Kalle> technology, and the implications for the service provider
    Kalle> side. While I'm aware of the idea, and pretty much got the
    Kalle> hang of pre-trustrouter-eduroam-routed moonshot, I'm trying
    Kalle> to understand the role on the trust router framework in this.

We're happy to try and help.

    Kalle> So, if I'm not completely mistaken, pre-trust router moonshot
    Kalle> could basically be seen as a alternative (to http+browser)
    Kalle> way of passing SAML messages between IdPs and SPs? And even
    Kalle> with trust router, the purpose of moonshot is basically to
    Kalle> pass user attributes between a federation of IdPs and SPs?

I'd describe Moonshot as accomplishing several goals:

1) Perform authentication from a user to an IDP

2) Establish trust between an SP and IDP

3) Convey attributes about SP to IDP

4) Convey attributes about IDP to SP

5) Convey attributes about authenticated user to SP

6) Establish cryptographic key between user and SP

From the standpoint of Moonshot, SAML is one mechanism for conveying
attributes about a user to an SP.
SAML can also have a role in conveying attributes about the SP and IDP
but we haven't really focused on doing that. It's possible, just not our
focus.



    Kalle> I have read through the trust router and moonshot RFCs, and I
    Kalle> have some kind of an idea what it's about. However there are
    Kalle> a few questions that I thought about.

    Kalle> The moonshot SAML additions don't require the IdP assertions
    Kalle> to be signed. Is this because the trustrouter framework
    Kalle> should securely connect the SP to the IdP, so that the
    Kalle> channel can be trusted, and you don't need additional
    Kalle> verification that it is the actual IdP that has issued the
    Kalle> assertion, and that it's the actual SP requesting it?

For Moonshot to give the security guarantees you'd like, Moonshot
requires the channel between SP and IDP to be secure.
Because of that, the assertion need not be signed.
We think trust routter is the best way of securing that channel and yes,
trust-router does provide that security.
However, Moonshot has required that channel be secure since the
beggining. We've always been interested in RADSEC because we needed a
secure channel.
So, trust router is how we plan to secure the channel, but trust router
didn't bring the requirement for channel security.

    Kalle> What is the role (if any) of the SAML metadata in this?

You don't need SAML metadata with a working trust-router arrangement.

There are cases where it might be useful for things on top of Moonshot.
Moonshot uses the Shibboleth SP, so Moonshot can take advantage of SAML
metadata, but Moonshot does not require SAML metadata.

    Kalle> Should trust router replace the need of a federation wide
    Kalle> metadata? If so, how will and IdP decide what user attributes
    Kalle> to release to which SP? Will any SP be able to request any
    Kalle> attributes for a user (what are the privacy ramifications for
    Kalle> this?)

You don't need  SAML metadata to use moonshot.

In general, we expect people will use the community of interest
mechanism within the trust router
to decide what rules govern attribute release, privacy and the like.

Many COIs will make it clear what the release requirements need to be.

However, a COI could do a number of things if it matters:

* Use SAML metadata to set release policies

* Include a SAML request in the access accept requesting specific
  attributes

* Include some information about desired attributes in the RADIUS access
  accept

* Use IDP policy based on the gss acceptor attributes included in RADIUS
  requests.



    Kalle> Will each moonshot service provider (e.g. ssh on
    Kalle> moonshottest.csc.fi) basically be seen as a separate service
    Kalle> provider SAML-wise? Depending on the answer to the question
    Kalle> above, each of these will be registered to the trust router
    Kalle> framework and/or added to a federation SAML metadata?

The entity ID for each service is up to the community of interest.
There are two ways I can see handling this:

* If the IDP's radius server symthesizes a SAML request then the IDP is
responsible for picking an appropriate entity ID to get the right
release policy.
This is easiest and is probably what will happen. The RADIUs server has
attributes that would allow it to pick a different entity ID for each
ssh server, use the same for all ssh servers in an SP realm, or use the
same for all moonshot services in an SP realm.
(Or use the same for all moonshot services in a community)


* If  a SAML request is generated,
then obviously that can pick the entity ID.

    Kalle> Since moonshot/trustrouter isn't a completely simple thing
    Kalle> (for me at least), I don't rule out that I'm wrong on all
    Kalle> accounts and in my base assumptions :). Also, if these get
    Kalle> answered, I'm not promising I'll come up with a load of more
    Kalle> questions.

we appreciate the questions.
It sounds like you're generally understanding what is going on.