Subject: [abfab] New version (-01) of use case I-D

From: Rhys Smith <[email-masked]>
Date: Tue, 5 Jul 2011 21:54:02 +0100

Just posted a -01 of the use case doc. See App A for details of changes - added a few use cases as suggested during and since the last IETF gathering, and rewording some bits here and there. Still some to do... Comments obviously welcome!

http://www.ietf.org/id/draft-ietf-abfab-usecases-01.txt

Regards,
Rhys.
--
----------------------------------------------------------------------
Dr Rhys Smith                                   e: [email-masked]
Engineering Consultant: Identity & Access Management  (GPG:0xDE2F024C)
Information Services,
Cardiff University,                            t: +44 (0) 29 2087 0126
39-41 Park Place, Cardiff,                     f: +44 (0) 29 2087 4285
CF10 3BB, United Kingdom.                      m: +44 (0) 7968 087 821
----------------------------------------------------------------------

---

From: Gabriel López <[email-masked]>
Date: Wed, 06 Jul 2011 10:42:00 +0200

Hi Rhys,

Alejandro sent a few months ago the campus use-case. I see it is not
included in the -01 version.
Just to know whether do you think this case is not interesting for
abfab, pending to be added, or it is just a mistake :)

Best regards, Gabi.

El 05/07/11 22:54, Rhys Smith escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt
From: Alejandro Perez Mendez <[email-masked]>
To: [email-masked]
Date: Tue, 29 Mar 2011 13:30:43 +0200
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>

Hi Rhys,

following you can find UMU's first draft for the campus use case. 
Comments are welcome.

CAMPUS USE CASE
---------------------------------

Universities usually offer different kind of services to their students 
and staff, ranging from basic network access to the more advanced campus 
intranet, passing through services such as remote computing systems, 
storage, mail and printing services, etc. Access control to these 
services is usually managed by means of end user’s login and password.

Although it is fairly extended that users can make use of the same 
credentials to access different services, thanks to a central identity 
information storage center within each university (e.g. LDAP or 
database), the authentication mechanism usually differs for each 
service. This heterogeneity leads to deployment and usability problems, 
as most of the authentication and authorization functionality must be 
implemented on each service that the university deploys. Usability 
issues are related with the lack of a Single Sign-On (SSO) service, 
avoiding users to re-introduce their credentials on each service access, 
and the existence of several configuration points where the user needs 
to configure authentication-related aspects (web browser, network 
supplicant, mail user agent, remote access software, etc...).

The issues described above are motivating service administrators to look 
for access control solutions that can be applied to a wider range of 
services. An example of this would be the deployment of CAS – Central 
Authentication Service (http://www.jasig.org/cas) as an authentication 
and SSO solution suitable for web services, or Kerberos [RFC 4120], 
broadly used to provide authentication and SSO for services like SSH, 
SMTP or POP. However, an integrated solution that can be applied to a 
wider range of services is still missing.

Beside, in order to help mobility of students and staff between 
different universities, there exists an increasing interest to provide 
these services also to users coming from other universities or 
organizations. These /foreign /users should be able to access the 
services at the /remote /institution making use of the credentials 
provided by their /home/ University, without the need of creating a new 
user profile for them in the visited one. This interest for federated 
services has already been demonstrated with the expansion of /eduroam 
/(_www.eduroam.or <http://www.eduroam.or/>_g), the secure international 
roaming network service that allows users belonging to one institution 
to get network access when visiting another institution. This federation 
is based on the deployment of EAP (Extensible Authentication Protocol) 
for authentication and a hierarchy of RADIUS servers for authorization 
and accounting. However, eduroam only covers the network access control, 
but has nothing to do with access control to upper layer services. 
Besides, several approaches to federate these upper layer services exist 
(e.g. Shibboleth, OpenID...), and some of them have even been deployed 
in several universities to manage access to specific services [SIR], but 
they are intended for web-based oriented services and do not apply to 
other application services.

For example, some universities have shown interest for using federated 
SSH. RedIris (http://www.rediris.es) deployed a proposal (FedSSH) for 
the Spanish Supercomputing Network. Also, the Internet2 web page 
describes future work on a Federated SSH toolset 
(_https://spaces.internet2.edu/display/COmanage/Functional+Roadmap_). 
Other federated services of interest, besides SSH and web-based 
services, are network storage (where students can store files related 
with different subjects and access them from any place within the 
campus) based on NFS (Network File System) or CIFS (Common Internet File 
System).

Hence, it is envisioned that universities will be very interested on a 
solution that can provide an unified and federated access to their 
services based on the already deployed AAA infrastructure (i.e. 
eduroam), providing an homogeneous authentication and SSO alternative 
that, on the one hand, simplifies deployment of new services, and on the 
other, improves their usability.

Best regards,
Alejandro

> Obviously happy to receive any additional use case text people think is important.
>
> Federated ssh is something that is a prime factor of the Grid and/or HPC use-cases already included in the 00 draft - though both use cases don't currently mention any specific technologies (e.g. the current text of "federated access to HPC systems" is pretty vague). Those technologies, including federated SSH, should probably be more specifically enumerated in the next draft...
>
> But a more generic use case discussing federated access to organisational services such as SSH, SMTP, and whatnot does seem probably worth including. All text gratefully received!
>
> Regards,
> R.
>
>
> On 8 Mar 2011, at 07:38, Gabriel López wrote:
>
>> Hi,
>>
>> I always thought in the campus use case like a good example for this wg. I mean, students and professors roaming between universities and requesting federated access to service such as FTP, SSH, SMTP, etc. etc. Something that eduroam is not providing currently. Do you plan on the description of this scenario in the draft?
>>
>> Best regards, Gabi.
>>
>> El 08/03/11 02:30,[email-masked]  escribió:
>>> A new Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.
>>>
>>>      Title         : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases
>>>
>>>      Author(s)     : R. Smith, et al
>>>      Filename      : draft-ietf-abfab-usecases-00.txt
>>>      Pages         : 7
>>>      Date          : 2011-03-07
>>>
>>> Federated authentication is most commonly associated with Web-based
>>>     services, but there is growing interest in the application of
>>>     federated authentication for non-Web services.  The goal of this
>>>     document is to drive the development of requirements.
>>>
>>> A URL for this Internet-Draft is:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>>
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>
>>> _______________________________________________
>>> abfab mailing list
>>>
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/abfab
>> -- 
>> ----------------------------------------------------------------
>> Gabriel López Millán
>> Departamento de Ingeniería de la Información y las Comunicaciones
>> University of Murcia
>> Spain
>> Tel: +34 868888504
>> Fax: +34 868884151
>> email:
>> [email-masked]
>> _______________________________________________
>> abfab mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/abfab
> --
> Dr Rhys Smith                                   e:[email-masked]
> Engineering Consultant: Identity&  Access Management  (GPG:0xDE2F024C)
> Information Services,
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

---

From: Rhys Smith <[email-masked]>
Date: Wed, 6 Jul 2011 18:49:23 +0100

I haven't added it yet; mostly because to me it reads more like a series of use cases applicable to a single context as it stands.

Personally I think it's better to concentrate on the individual use cases (e.g. ABFABbed printing, ABFABbed database/directory access, ABFABbed HPC services, ABFABbed SIP, etc) which are valid in any domain (be it campus or enterprise or whatever) than on describing a variety of use cases in specific contexts (e.g. the campus use case, the small enterprise case, the large enterprise case, the health provider case, etc. etc.).

The reason for that is that I fear that people out of the academic environment may not empathise with it if it's framed as a "campus" use case even when the details may be very applicable to them. Hence why I'm trying to draw out each particular use case separately and make it applicable in a variety of contexts. Also, there's going to be some degree of overlap in use cases between contexts.

I'm obviously happy to change this if the consensus is to do so, but I'm currently of the opinion that this is the better way to do it - anybody have any thoughts?

R.

On 6 Jul 2011, at 09:42, Gabriel López wrote:

> <Mensaje adjunto.eml>