Dear Diego,



"Diego R. Lopez" wrote:

> Dear Sassa,
>
> [>>could PERMIS API be used in PAPI?]
> > Yes, and that is the reason I am studying the access control systems
> > now that are available worldwide.
>
> That's really good news!
>
> > Your PoA would have a Policy saying what roles (groups) the user has
> > to belong to in order to have access to a particular resource, and
> > also state what SOAs (universities, departments) can issue Attribute
> > Certificates to prove the user is a member of the group (is assigned a
> > role). Then a user could:
> >
> > 1. Access PoA, and PoA would call our API, which would retrieve the
> > ACs from LDAP repository and make an access decision

Note that our API can use multiple LDAPs simultaneously - e.g., one LDAP per
institution you have an agreement with.


> > or
> >
> > 2. Access AS, which would store a set of relevant ACs and send them to
> > the user in the same way as the authentication information is passed
> > on to the PoA in your current model. Then the PoA would push the
> > received ACs to the Permis API and it would deliver the decision, as
> > the policy prescribes.
>
> How long are the ACs you use? We send the authentication information to
> the PoA encoded inside URL parameters (using the GET HTTP method). In case
> of really long authentication data, POST should be used and there would
> necessary to evaluate how this may impact user-system interaction
> (usability has been one of our major goals).

Good point. However, we did not study that yet. I can tell that the size
varies from about 150 bytes to about 500 bytes. The Policy AC is typically
around 3K-4K bytes long (because of the XML embedded), but it is loaded only
once, when the system starts up.

Note also that the ACs can be cached - you don't need to send/retrieve them
every time. At the other level our API also provides ready-to-use credentials
(representation internal to the API), which you can cache as well, to be able
to make a few subsequent calls without invoking network operations to retrieve
the ACs, and without any cryptography as well (ACs are valid for a certain
period of time, as specified in them).


We have a tool with GUI for creating and signing ACs. At the moment we have an
extension to let Entrust PKI users sign them, and we are considering if it is
practical to have an extension for signing ACs with a private key generated
using openSSL. We would be happy if you could comment on this, since you have
a working web-based system with digital signing in place, and perhaps you know
about others as well. How do they cope with that there could be many different
PKIs from various vendors? Or do they stick to a particular PKI? Do you have
an insight into the situation with web-based applications?

We were targetting a wider set of users, therefore we could not focus on any
particular PKI; besides, the requirements were different for each of the three
partners piloting our API. So we had to invent the extension mechanism. Also
our partners are mainly using an external application for creating a signed
content, so the situation is a bit different from what is happening on the
web.

So in order to make a "spot-on" decision on what kind of PKI extension would
be of most use to a web-based application with TLS/SSL, we would appreciate
your advice. What tool set is the common practice, how the private keys are
stored, differences between Apache and MS-IIS web-servers (any other major
implementations?) in this sense. I hope that since you already have your
system running, you might have a paper discussing similar issues leading to
your choice and solution, or may be you know the key sites, or papers with
overviews of tendencies in this area. Such information would really help us
understand the needs of web-based applications and develop extensions to make
integration even easier.


> > 1. a policy external to the PoA (our code copes with it, not yours),
> > 2. the authorisation tokens would be cryptographically protected,
> > 3. the authorisation tokens would not contain any direct privilege
> > ("can access a resource"), only an indirect statement that a user is
> > of a particular kind, and

> >
> > 4. the OWNER of the resource specifies the actual access rights. In
> > the current model the AS is trusted to issue the correct amount of
> > privilege: if the owner wants to restrict access, he will have to tell
> > each AS to change the rights (as I understand your system). In
> > Permis-based system the owner changes the policy (changes the XML of
> > it and re-issues the Policy Attribute Certificate) - and the access
> > rights change (session length? role type? role value? operation to
> > perform? location to access?).
>
> Externalizing the access policy would be really a great advantage. In
> the current PAPI model, the owner of the resource can set specific access
> rights by means of "filters" (using the directive "PAPI_Filter") that
> we are going to enhance in the next release. Nevertheless, these filters
> are embedded in the server configuration, so their access and management
> is cumbersome, and are not so flexible as your authorization engine.
>
> I hope this will be the start of an evolution of our systems that allow
> their integration in more powerful, and easy to manage and use AA systems.

Finally, here is the URL for our site, in case you want to study the
documentation.

http://sec.isi.salford.ac.uk/permis/

I am also Cc-ing the letter to David Chadwick, who is the leader of the
project, in case he wants to add anything to our discussion.


Sassa

>
>
> Best regards,
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Diego R. Lopez
> [log in para visualizar]
>
> RedIRIS
> The Spanish NREN
> Tel:    +34 955 056 621
> Mobile: +34 669 898 094