Subject: [sacm] Authentication and Authorization for Content Repository

From: "Chandrashekhar B" <[email-masked]>
Date: Tue, 6 Nov 2012 19:15:14 +0530

There were some discussion on this topic earlier and it was somewhat
concluded that authorization and access control should not be part of the
standardization effort, as it brings-in complexity. As an effort to make
SCAP Repo's web service authentication and authorization seamless and
support subscription services, we took up an exercise to think through
various options. 

We currently have User ID and Password based mechanism, which will not work
in an automated environment. 

SSL mutual certificate based authentication is another option but, brings
its own complexity and there are no authorization statements in a standard
certificate. 

After looking at few other non-standard option, we thought SAML
authorization assertion is the way to go and it binds well to the enterprise
SSO implementations. So, keeping the IDP and token issuance out of scope
from the standardization point of view, we can ask the repository <->
repository or client <- > repository interactions come with SAML
authorization token. SAML token can be sent part of the HTTP Authorization
Header (compressed), which fits well with the RESTful web service model. 

Any thoughts on this? 

Thanks,

Chandra.

---

From: David Solin <[email-masked]>
Date: Tue, 06 Nov 2012 08:05:32 -0600

Hi Chandra,

Authentication and authorization should be handled exclusively at the 
HTTP/(S) layer.  This would allow for Basic, Digest, NTLM, Kerberos, SSL 
certs, SAML, etc. -- whatever it is that the repository specifies.  
(Incidentally, the standard practice for a web server to use client 
certificates for authorization purposes is to implement a certificate 
mapping).

So, I see no reason why use of SAML should be required by the 
specification; it should be completely agnostic in this regard.

Regards,
--David Solin

On 11/6/2012 7:45 AM, Chandrashekhar B wrote:
> concluded that authorization and access control should not be part of 
> the standardization effort, as it brings-in complexity. As an effort 
> to make SCAP Repo's web service authentication and authorization 
> seamless and support subscription services, we took up an exercise to 
> think through various options.
>
> We currently have User ID and Password based mechanism, which will not 
> work in an automated environment.
>
> SSL mutual certificate based authentication is another option but, 
> brings its own complexity and there are no authorization statements in 
> a standard certificate.
>
> authorization assertion is the way to go and it binds well to the 
> enterprise SSO implementations. So, keeping the IDP and token issuance 
> out of scope from the standardization point of view, we can ask the 
> repository <-> repository or client <- > repository interactions come 
> with SAML authorization token. SAML token can be sent part of the HTTP 
> Authorization Header (compressed), which fits well with the RESTful 
> web service model.
>
> Any thoughts on this?
>
> Thanks,
>
> Chandra.
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

-- 

jOVAL.org: SCAP Simplified.
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

---

From: Gunnar Engelbach <[email-masked]>
Date: Tue, 06 Nov 2012 09:15:31 -0500

I can see how that would add some measure of convenience for interactive 
use, but after initial setup an application doesn't care about the 
inconvenience of going through an authentication query/response step. 
It also requires that the user has access to a SAML ID server (or that 
every repository also set one up) and that the application is capable of 
accessing that server.  Those two factors mean that accessibility will 
be less than 100%.

I think it would be easier to start with the most basic an universal 
case, such as HTTP basic auth (preferably over SSL) and SSL certificate 
authentication.  With those available we can then think about other 
options that are more convenient.

--gun

On 11/6/2012 8:45 AM, Chandrashekhar B wrote:
> the standardization effort, as it brings-in complexity. As an effort to
> make SCAP Repo’s web service authentication and authorization seamless
> and support subscription services, we took up an exercise to think
> through various options.
>
> brings its own complexity and there are no authorization statements in a
> standard certificate.
>
> Authorization Header (compressed), which fits well with the RESTful web
> service model.
>
> Any thoughts on this?
>
> Thanks,
>
> Chandra.
>
>
>

---

From: Luis Nunez <[email-masked]>
Date: Tue, 6 Nov 2012 09:18:24 -0500

initial thoughts are to look at the Resource Oriented Lightweight Indicator Exchange draft:
http://tools.ietf.org/html/draft-field-mile-rolie-00 
Rolie is on the MILE agenda we should review.

We may also want to look at the what the kitten working group is doing in this area 
 https://datatracker.ietf.org/doc/charter-ietf-kitten/

-ln

On Nov 6, 2012, at 9:05 AM, David Solin wrote:

> Hi Chandra,
> 
> Authentication and authorization should be handled exclusively at the HTTP/(S) layer.  This would allow for Basic, Digest, NTLM, Kerberos, SSL certs, SAML, etc. -- whatever it is that the repository specifies.  (Incidentally, the standard practice for a web server to use client certificates for authorization purposes is to implement a certificate mapping).
> 
> So, I see no reason why use of SAML should be required by the specification; it should be completely agnostic in this regard.
> 
> Regards,
> --David Solin
> 
>> There were some discussion on this topic earlier and it was somewhat concluded that authorization and access control should not be part of the standardization effort, as it brings-in complexity. As an effort to make SCAP Repo’s web service authentication and authorization seamless and support subscription services, we took up an exercise to think through various options.
>>  
>> We currently have User ID and Password based mechanism, which will not work in an automated environment.
>> SSL mutual certificate based authentication is another option but, brings its own complexity and there are no authorization statements in a standard certificate.
>>  
>> After looking at few other non-standard option, we thought SAML authorization assertion is the way to go and it binds well to the enterprise SSO implementations. So, keeping the IDP and token issuance out of scope from the standardization point of view, we can ask the repository <-> repository or client <- > repository interactions come with SAML authorization token. SAML token can be sent part of the HTTP Authorization Header (compressed), which fits well with the RESTful web service model.
>>  
>> Any thoughts on this?
>>  
>> Thanks,
>> Chandra.
>> 
>> 
> Learn More | Features | Download
>

---

From: "Chandrashekhar B" <[email-masked]>
Date: Wed, 7 Nov 2012 11:38:22 +0530

I probably started thinking too much J

This is somewhat akin to an Antivirus product getting a signature update
from the server, am not sure what authorization mechanism they use.
Authenticate each time and then determine what they are entitled to or
present a token signed by the server?

I was also coming from the need to support subscription based service. A
single user interested in multiple subscriptions for multiple of his
scanners, creating multiple users or issuing multiple certificates vs.
creating multiple signed tokens should be weighed. 

This is too implementation specific to be left to the repo creator? May be
yes.

Thanks,

Chandra.

From: David Solin [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2012 7:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] Authentication and Authorization for Content Repository

Hi Chandra,

So, I see no reason why use of SAML should be required by the specification;
it should be completely agnostic in this regard.

Regards,
--David Solin

Any thoughts on this? 

Thanks,

Chandra.

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / Virus Database: 2617/5873 - Release Date: 11/04/12

---

From: "Chandrashekhar B" <[email-masked]>
Date: Wed, 7 Nov 2012 11:51:05 +0530

>I can see how that would add some measure of convenience for interactive
use, but after initial setup an >application doesn't care about the
inconvenience of going through an authentication query/response step. 
>It also requires that the user has access to a SAML ID server (or that
every repository also set one up) and that >the application is capable of
accessing that server.  Those two factors mean that accessibility will be
less than >100%.

Agree.

>I think it would be easier to start with the most basic an universal case,
such as HTTP basic auth (preferably >over SSL) and SSL certificate
authentication.  With those available we can then think about other options
that >are more convenient.

>From the point of making the authentication, authorization process seamless,
cert based auth meets that need. As I highlighted in another mail, the need
was also to issue subscription authorization tokens and I felt SAML
authorization assertions are slightly lighter. 

But, yes in an enterprise scenario, the repo should work with the
authentication and authorization schemes that are already implemented. 

-----

---

From: David Solin <[email-masked]>
Date: Tue, 06 Nov 2012 08:04:40 -0600

Hi Chandra,

Regards,
--David Solin