Subject: [abfab] Naming of SAML and AAA systems

From: Josh Howlett <[email-masked]>
Date: Tue, 11 Jun 2013 13:52:22 +0000

I'm currently updating abfab-aaa-saml. The document is a bit unambiguous
about the naming of system entities, specifically:

 1. There is no attempt to correlate the AAA and SAML entity naming (the
transport and message levels respectively). I believe that we need a
naming convention such that it is trivial to reliably infer a system
entity's AAA or SAML name, given the other name.

 2. We don't yet have a mechanism for naming the functional roles of SAML
entities within a realm, which I believe is needed to satisfy the
attribute request and aggregation use cases. For example, an acceptor
wanting additional attributes for an authenticated user from realm Foo
from another attribute authority in realm Bar.

Here's my proposal:

 * A SAML system names itself using an entity identifier is a URI that
encodes the AAA system's FQDN. For example "abfab:idp.example.com" and
"abfab:rp.example.com" would name two hosts with FQDNs of idp.example.com
and rp.example.com. For an RP, this entity identifier value (less the
abfab prefix) will therefore be equal to the value of the
GSS-Acceptor-Host-Name RADIUS attribute. It is worth noting that section
4.3 of RFC3588 specifies a URI scheme for AAA protocols, but it looks a
bit elaborate for what we need (and possibly not complete, given the
RADIUS transport options today). Irrespective of the convention we choose,
RADIUS entities emitting SAML messages MUST use it.

 * SAML system entities are able to locate SAML entities within other
realms using RADIUS by using well-known values for the user fragment of
the NAI. For example, a relying party would resolve an attribute authority
in realm by using an NAI with value "abfab:[email-masked]". This might
return a SAML assertion issued by an entity named "abfab:idp.example.com".
Similarly an authorisation PDP might be resolved using
"abfab:[email-masked]".

Opinions?

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Jun 2013 16:24:26 +0100

Hi Josh

I guess you have two options
i) some sort of directory or metadata or config file in which names are 
listed and there is no requirement for them to be algorithmically 
related to each other, or
ii) having a mandatory naming convention that specifies how related 
entities are named, and from which you can determine the relationships.

Going with ii) suffers from problems if the relationships that are 
implicitly assumed in the naming convention turn out to be different in 
practice e.g. you assume 1 to 1 relationships between entities but they 
turn out to be 1 to n or n to n. Also what happens if new (sub)types of 
entities arise? You might end up having to change the code base to 
support them.

I think i) is safer, but it has additional costs of requiring support 
for the directory/discovery mechanism

regards

David

On 11/06/2013 14:52, Josh Howlett wrote:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 19 Jun 2013 15:17:48 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Josh Howlett
> Sent: Tuesday, June 11, 2013 6:52 AM
> To: [email-masked]
> Subject: [abfab] Naming of SAML and AAA systems
> 
naming
> convention such that it is trivial to reliably infer a system entity's AAA
or
> SAML name, given the other name.

I am not sure what this statement means.   We have defined an NAI identifier
format for use in SAML certificates so that there is a way to have common
naming for the client entities between the two systems.  Are you trying to
look at how to do naming for the AAA server and the SAML entity server?

> entities within a realm, which I believe is needed to satisfy the
attribute
> request and aggregation use cases. For example, an acceptor wanting
> additional attributes for an authenticated user from realm Foo from
another
> attribute authority in realm Bar.

This is an interesting question, do you have a case where you want to do
this? 

I am also not sure how one would go about sending such a message, are you
going to use AAA for routing the SAML request based on the domain you want
to send it to?  Is there a reason to expect that the AAA server at that
location wouldn't just somehow know what to do?

Jim

>  * A SAML system names itself using an entity identifier is a URI that
encodes
> the AAA system's FQDN. For example "abfab:idp.example.com" and
> "abfab:rp.example.com" would name two hosts with FQDNs of
> idp.example.com and rp.example.com. For an RP, this entity identifier
value
> (less the abfab prefix) will therefore be equal to the value of the GSS-
> Acceptor-Host-Name RADIUS attribute. It is worth noting that section
bit
> elaborate for what we need (and possibly not complete, given the RADIUS
> transport options today). Irrespective of the convention we choose, RADIUS
> entities emitting SAML messages MUST use it.
> 
realms
> using RADIUS by using well-known values for the user fragment of the NAI.
> For example, a relying party would resolve an attribute authority in realm
by
> using an NAI with value "abfab:[email-masked]". This might return a SAML
> assertion issued by an entity named "abfab:idp.example.com".
not-for-
> profit company which is registered in England under No. 2881024 and whose
> Registered Office is at Lumen House, Library Avenue, Harwell Oxford,
Didcot,
> Oxfordshire. OX11 0SG. VAT No. 614944238
>

---

From: David Chadwick <[email-masked]>
Date: Thu, 20 Jun 2013 08:39:22 +0100

>> >attribute authority in realm Bar.

I believe the only way you can do this is by having global role names, 
and knowledge about who issues which roles. (In general there is a many 
to many mapping of roles to issuers.) Hierarchical role naming such as 
realm.role is one way of achieving this for locally named roles, but 
those roles that are already globally named dont need this hierarchical 
naming, and re-naming a global role (say globalrole) realm1.globalrole 
and realm2.globalrole would not be correct.

David

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jun 2013 10:16:14 -0400

Josh, in the case where someone is deploying SAML infrastructure
specifically to work with ABFAB, I think it ought to be relatively easy
to map naming between AAA and SAML.

However, I don't understand how to do this in the case where we're
using existing SAML infrastructure for ABFAB.

--Sam

---

From: Leif Johansson <[email-masked]>
Date: Thu, 20 Jun 2013 16:20:58 +0200

> using existing SAML infrastructure for ABFAB.
This gets you into SAML metadata territory.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jun 2013 14:02:47 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> On 06/20/2013 04:16 PM, Sam Hartman wrote:
    >> specifically to work with ABFAB, I think it ought to be
    >> relatively easy to map naming between AAA and SAML.
    >> 
    >> However, I don't understand how to do this in the case where
    >> we're using existing SAML infrastructure for ABFAB.
    Leif> This gets you into SAML metadata territory.

I think Josh was looking for something structural.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 21 Jun 2013 22:30:30 +0200

> I think Josh was looking for something structural.

SAML metadata is plenty structural :-)

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 21 Jun 2013 14:57:10 -0700

Yes - but we still don't know what type of problem he thinks he is solving.

Jim

> Of Sam Hartman
> Sent: Thursday, June 20, 2013 11:03 AM
> To: Leif Johansson
> Cc: [email-masked]
> Subject: Re: [abfab] Naming of SAML and AAA systems
>