SSO BasicAA

[Giuliano Taffoni]

Hi Mark
Well this document is just a reference to existing standards. It tells you that if you find 
a securitymethod called BasicAA then you have to implement a client that it is able to send a 
User name and password according to the RFC7617 (this is the correct one, anyway read also 
RFC2616 that introduce the concept of HTTP Authentication)

As far as I remember the BasicAA was introduced in v2.0 doc because of back-compatibility 
issues. However you must implement TSL to encrypt the traffic, this wlll not expose
passwords in the web but only to the server (this is unavoidable with BasicAA).

Anyway, the idea is that in this document we are introducing a naming convection for the
Auth mechanism so that we should be able to make client and servers to dialog.
Regards
G.

PS: we need to make  an errata for tel with passwd and to set the proper reference to the RFCs. 



> On 2 Apr 2019, at 18:00, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> Pat,
> 
> thanks, that does help to orient me a bit.  I have to admit that with
> the SSO spec I always have the feeling that I don't know what it's
> talking about.  The underspecification of section 7 is part of that.
> This may be partly because I'm just thinking about it from the point of
> view of how these security method IDs are used in (e.g.) TAP, which is
> not the whole picture.
> 
> Some of my comments (e.g. reference to incorrect RFCs) still stand
> and should be considered for a future version or as Erratum fodder.
> But in the mean time I'll try and make sense of it the best I can
> for implementation.
> 
> Mark
> 
> 
> On Tue, 2 Apr 2019, Patrick Dowler wrote:
> 
>> Responses in no particular order:
>> 
>> - in general the language in SSO encourages use of TLS (https) when sending
>> senistive info but does not ban http
>> 
>> - I am probably to blame for that #BasicAA securityMethod in the first
>> place (we started using a w3.org URL that ended in #BasicAA way back) and I
>> think it has to be taken to mean basic and not digest. Do we need a
>> #Digest? see below
>> 
>> The paragraph at the end of section 3 (before 3.1) says that in general
>> service endpoints should be using #Oauth, #cookie, #tls-with-certficate
>> and/or allow anon. Special "login" endpoints where you get such tokens
>> (oauth and cookie) should be using #tls-with-password,
>> #tls-with-certifcate, and/or #saml2.0 -- you will note that #BasicAA
>> doesn't appear anywhere in this recommendation! I think it is for all the
>> same reasons that TAP-1.1 was hard and we had that meeting in Trieste :-)
>> It could be because #BasicAA is inherently the opposite of SSO (!single :
>> you sign in every time) but I think that paragraph is just somewhat more
>> prescient about the way things would/should go.
>> 
>> So, SSO also seems to leave #BasicAA off to the side as the thing that
>> doesn't fit the big picture. That probably doesn't help client writers come
>> up with a strategy but I would say to keep the concepts in that paragraph
>> in SSO in mind as it captures the way things will work now and in future.
>> 
>> 
>> Aside: One thing that is seems missing is an actual spec for
>> #tls-with-password. When I read section 7 it says the username and password
>> are passed in the message body but doesn't specify exactly how (2 params? 2
>> parts with separator? simple doc format?). Now that I read it again, 7.2
>> really confuses me :-) Anyway, I have some ideas on what to do with this
>> issue that are related to another email thread on standardising "login" to
>> an SSO realm.
>> 
>> --
>> Patrick Dowler
>> Canadian Astronomy Data Centre
>> Victoria, BC, Canada
>> 
>> 
>> On Tue, 2 Apr 2019 at 03:45, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
>> 
>>> Hi GWS.
>>> 
>>> I'm looking at the SSO 2.0 standard, specifically section 4,
>>> "HTTP Basic Authentication", and there are some points I would like
>>> to have clarified.  The text says this:
>>> 
>>>   "Services using HTTP basic authentication SHALL use the authentication
>>>    mechanism described in the RFC7235 (Fielding, 2014) that updates
>>>    RFC2617 (Franks and Hallam-Baker et al., 1999). Interfaces using this
>>>    mechanism SHALL be registered with the security method
>>>    ivo://ivoa.net/sso#BasicAA"
>>> 
>>> But the RFCs referenced here don't really match the text.
>>> 
>>> RFC 2617 defines approximately three things:
>>> 
>>>   [A]: challenge/response framework, i.e 401 HTTP response etc (section 1)
>>>   [B]: Basic authentication scheme (section 2)
>>>   [C]: Digest authentication scheme (section 3)
>>> 
>>> RFC 7235 on the other hand really just talks about [A].
>>> RFC 2617 is obsoleted by more than one document, in particular:
>>> 
>>>   [A]: discussed in RFC 7235
>>>   [B]: discussed in RFC 7617
>>>   [C]: discussed in RFC 7616 (and maybe RFC 7615)
>>> 
>>> The Commentary section 4.2 in SSO is not particularly clearly worded,
>>> but from the text:
>>> 
>>>   "The 'HTTP basic authentication' SHOULD be used with particular
>>>    attention as sensible information (password) are sent over the
>>>    wire in base64 encoding"
>>> 
>>> it seems that it is talking specifically about [B].  At the least
>>> therefore, I think that SSO section 4 ought to include a reference
>>> to RFC 7617 instead of, or possibly as well as, RFC 7235.
>>> 
>>> Even so however, I'm still not certain exactly what is required from
>>> a service that declares a SecurityMethod ivo://ivoa.net/sso#BasicAA.
>>> In particular, does it have to use the "Basic" authentication scheme
>>> ([B]), or is it permitted to use "Digest" ([C]) or other non-standard
>>> authentication schemes permitted by the HTTP authentication
>>> framework ([A])?  I'm guessing that [B] is required, but it would
>>> be nice to have this made explicit in the text.
>>> 
>>> Thinking further along these lines: if BasicAA does indeed mandate [B],
>>> maybe we should add another SecurityMethod option for the Digest
>>> authentication scheme [C].  Although the authors of RFC 7616 are at
>>> pains to point out that Digest authentication is not a total solution
>>> to security over HTTP(S), it does provide user/password authentication
>>> without sending passwords over the wire, so it's a whole lot better
>>> than Basic, it likely provides security strong enough for the kind
>>> of thing astronomers (and maybe even data centers) care about, and
>>> it's probably a lot less effort than something like OAuth.  I'm not
>>> necessarily advocating this, since another Auth option becomes another
>>> implementation burden for client authors, but it could be worth
>>> bearing in mind.
>>> 
>>> While I'm griping about this section, some clarification about use of TLS
>>> would be nice too; it currently says "Connection secured with TLS are
>>> RECOMMENDED prior to exchanging any credentials."  I *think* what it
>>> means is that if you're using BasicAA it's a good idea to do it over
>>> HTTPS rather than HTTP, but I'm not certain.
>>> 
>>> Mark
>>> 
>>> --
>>> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
>>> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>>> 
>> 
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/