The first caNl teleconference

Date 05.08.2010

Participants: [OK] Oscar, [JH] Joni, [MS] Mischa, [KB] Krzysztof

Topics: Discussion on the caNl requirements.

Summary

  1. It was agreed that TLS based authentication is required and in scope. We have detailed list of requirements in this field.
  2. Additionally (although strictly speaking it is not authN work) library should include support for proxy certificates generation.
  3. SAML Authentication support is controversial: it is required at grid border. It might be useful for other EMI components but this would require a significant changes in middleware. It can be used in limited number of cases today (whenever delegation is not needed). But the questions are: how the (especially unaware) user can distinguish that delegation is not required? Whether usage of SAML is anyhow simpler for the user in comparison to usage of (well implemented) SLCS with SAML authentication?
  4. Other then SAML AuthN and TLS means of authentication were not mentioned.
  5. We have identified the following targets where having a common API would be good:
    1. authentication: providing an authenticated client identity and establishing authenticated connection on the client side.
    2. user attribute retrieval: providing a common API returning set of the authenticated user's attributes (verified, parsed), regardless of their source (AC, SAML Attribute Assertion, X.509 certificate of the user). This is dependent on the common SAML profile, and definition of common SAML attributes. The question here is whether this API should also support active attributes retrieval, e.g. querying of the server?
    3. common XACML library, which definitely is not part of caNl.

Next steps

  1. Decide in the whole Security Area group whether caNl should support user attribute retrieval. Other possibilities: this task is moved to the SAML group, or although it is nive to have it we don't implement it.
  2. Decide whether we include other then authenticated TLS means of authentication. The only one possibility raised by DoW and us is SAML Authentication.

Minutes

Note: I'm not sure in few cases if I labeled correctly some statements as coming from Oscar and those may come from Mischa who used the same phone. Feel free to fix it.

Topic no. 1. 

[KB] Do we really need to include in caNl support for *generation* of all tokens supported
(regardless of what they are)? E.g. do we need to issue standard X.509 certs?

[OK] The only thing related to certificates that we need to generate are proxy certificates.

[KB] Agreed.

[OK] Might be nice to have support for generation of other tokens like normal certificates (e.g. for
testing purposes). The most important thing is to support delegation. Globus allows for doing this
in two ways: over a network protocol and during a security channel session when initiating data
streams.

[KB] Yes, I agree. We need Proxy certificates generation. We shall therefore wait for Aleksander
for clarifications why we need to be able to generate *all* kinds of tokens. 

[JH] I also think that we need to create Proxies. It is not strictly speaking authentication
domain, but it is anyway useful here. It is currently done in various places and differently. Would
be nice to unify this.

[OK] Yes, everybody does it. But I think that the idea is broader: to be able to generate, verify,
extract different kinds of tokens.

[KB] Right, but I don't agree that we need to generate all kinds of tokens. E.g. AC. The only place
where it is and is going to be generated is VOMS. So there is no sense to include it in a common
library used by all components.

[OK] I imagine that VOMS library will be base of the caNl so this is anyway included there.
Vinzenco also requires the ability to initiate connection to the VOMS service, creating the ACs,
sending them back and extracting.

[KB] I don't think Vincenzo mentioned generation of ACs in his requirements list. Only extraction
of data (ACs in this case) from the connection.

One general remark: we can't assume that voms lib is already a part of the caNl. caNl will serve
different middlewares, will be implemented in 3 languages and we must be more abstract now, when
defining requirements.

[OK] OK, we should generalise. We should define a list of supported tokens. 

[KB] What do you mean by support?

[OK] To generate, verify setup channels with those tokens. Everything that is native to this token.

[KB] But except of certificates we don't use any other tokens to setup connections. And except
proxies we don't have anything to be commonly generated.

[OK] Yes but for instance SAML is very flexible and can be used in many ways. We should unify them.

[KB] In general right. But this is a goal of different group - the SAML group to define common set
of attributes, ways of using them, a grid SAML profile.

[OK] Yes, SAML is very useful and we want to use it in many places.

[KB] Yes, but SAML support is a next point. Let's come back to the generation of tokens. IMO we
need to generate proxies and we all agree that this is useful. But I can't see any reason to
include generation of SAML assertions or AC or X.509 certs in the universal library. This
functionality is required only in one component (VOMS) and anywhere else. We shouldn't complicate a
very universal library with unnecessary features.

[OK] OK

[JH] What about generation of XACML assertions? 

[KB] This is authorization, far away from authentication. 

[JH] I'm wondering if it would be good to have a similar thing as caNl for XACML.

[KB] Yes, but again this is another area in security group in EMI.

2. topic

[KB] Let's move to the SAML support. I'm negative. First of all we won't use SAML authentication in
EMI. We can use it on a grid border (e.g. authenticate with shib, then get SLC). But SAML authN
won't be used for all grid components.

[OK] Other approach is to use portal with SAML authN and keep cert at the portal.

[KB] Yes, we do this in UNICORE too but this is also on the grid border. Certificates are anyway
used, and SAML authN is to the portal. Also usually not using anything grid specific but
standard component like Shib SP.

[OK] Yeah. There were some efforts to deeply integrate SAML authN with grid tools but I'm unaware
about results. It would be nice to do this. It is mostly because there are no tools.

[KB] I don't agree. It is impossible as we anyway need that user has certificate. She must sign
jobs, sign delegation assertions or proxies. Without priv. key it is not working. SAML authN is
easy but after you won't be able to use the whole grid.
Also EMI DoW state that we stay with certificates. We must make life easier for end users but we
won't resign from certificates.

[JH] I hope we will have a high level interface for authN, regardless of method underneath.

[OK] In some cases SAML authN may work (when no delegation is required).

[JH] We should have a common interface even without implementing SAML authN.

[KB] OK, in some limited cases SAML authN may work. But how users can distinguish the situation? 
Regardless of this how this should work? SAML authN is on different network protocol level. It is
dependent on container/web server. We have Tomcat and Axis2, or Jetty and Xfire. Or CXF. 
So this is complicated and not much in common. One step later, when we already have this assertion
in hand, we have to process it. This is target of the SAML group. So what will be *common*?

[JH] We will have to have different handles for different containers but there are only two or
three. But what is common is this interface over this that process the assertions.

[KB] Not that few as also we have a client side.

[JH] Yes. Also we should make this way that we have only really required.

[KB] OK, but what is this common part?

[JH] Validation (usually inside a container), parsing, extracting attributes.

[KB] But as this is the work of the common SAML library (so different effort) again. Or do you
propose to create a layer above this that will provide attributes (parsed, verified, unified form)
regardless of the source (SAML, AC)? 

[JH] Yes. Also to allow to write services not dependent on container.

[KB] I don't think it is possible as there are many other dependencies on container. But anyway
it's not our problem. 

Anyway don't you think that we have something that should be in two libraries: one around TLS layer
and 2nd around attributes retrieval, handling SAML/AC?

[JH] Yes, we need layers.

[KB] It seems the word 'library' is overloaded.

[OK] I also agree on layers.

[KB] Ok. TLS layer definitely in scope of our group. But as we have SAML group I think that this
SAML parsing etc. belongs to that area. Authentication is checking whether John is John. Not
parsing all John's attributes. Covering all security things would be just a HUGE effort. 

[OK] Yes, a major work.

[KB] Right so next steps are to decide (in the whole sec area) what is our scope with respect to
the other activities.

[all] Agreed.

-- KrzysztofBenedyczak - 05-Aug-2010

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2010-08-06 - unknown
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback