[prev in list] [next in list] [prev in thread] [next in thread]
List: jabber-jdev
Subject: Re: [jdev] Claims-based Authentication
From: Jonathan Dickinson <jonathan () dickinsons ! co ! za>
Date: 2010-06-04 7:24:17
Message-ID: COL116-W62B8AE8A3183A4E8154877F7D20 () phx ! gbl
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> Date: Thu, 3 Jun 2010 07:54:48 -0600
> From: stpeter@stpeter.im
> To: jdev@jabber.org
> Subject: Re: [jdev] Claims-based Authentication
>
> On 6/3/10 7:48 AM, Jonathan Dickinson wrote:
> > > Date: Thu, 3 Jun 2010 07:41:25 -0600
> > > From: stpeter@stpeter.im
> > > To: jdev@jabber.org
> > > Subject: Re: [jdev] Claims-based Authentication
> > >
> > > [...]
> > >
> > > 2. Why wouldn't the WS-* folks define a new SASL mechanism?
> >
> > The problem is the XML - WSF uses XML to do the exchange, to base64-ing
> > it wouldn't be the best (as per requirement from the SASL RFC). If that
> > lands up being the route taken they would probably only need to reserve
> > a namespace.
>
> I don't see why we couldn't embed XML. The point about Base64-encoding
> in RFC 3920 is that if you have XML character data that's content of the
> <auth/> element, it needs to be Base64-encoded. But for different
> authentication mechanisms we might define more elaborate approaches.
The real cracker is you can do far more with WSF than just plain-old authentication. \
You can pass the user identity around etc. but I guess that's another problem for \
another day.
> Unfortunately that might mean that the <auth/>, <challenge/>, and
> <response/> elements end up having a mixed content model (ick), like this:
>
> R: <stream:features>
> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
> <mechanism>EXTERNAL</mechanism>
> <mechanism>FOOBAR</mechanism>
> </mechanisms>
> </stream:features>
>
> I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
> mechanism='FOOBAR'>
> <some-xml-here/>
> </auth>
>
> /psa
>
Icky was what I thought initially as well; however it shouldn't affect systems which \
don't support WSF mechanisms because they would never select them. I think this is \
the cleanest way to do it (without resorting to even more icky base-64 encoding XML). \
I will experiment and see what I come up with. Thanks for the feedback. Slightly off \
topic of the XML issue - we should maybe reserve/standardize Bare JID/Full JID claims \
with OASIS.-- Jonathan Dickinson \
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
https://signup.live.com/signup.aspx?id=60969
[Attachment #5 (text/html)]
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<br>> Date: Thu, 3 Jun 2010 07:54:48 -0600<br>> From: \
stpeter@stpeter.im<br>> To: jdev@jabber.org<br>> Subject: Re: [jdev] \
Claims-based Authentication<br>> <br>> On 6/3/10 7:48 AM, Jonathan Dickinson \
wrote:<br>> >> Date: Thu, 3 Jun 2010 07:41:25 -0600<br>> >> From: \
stpeter@stpeter.im<br>> >> To: jdev@jabber.org<br>> >> Subject: Re: \
[jdev] Claims-based Authentication<br>> >><br>> >> [...]<br>> \
>><br>> >> 2. Why wouldn't the WS-* folks define a new SASL \
mechanism?<br>> > <br>> > The problem is the XML - WSF uses XML to do the \
exchange, to base64-ing<br>> > it wouldn't be the best (as per requirement from \
the SASL RFC). If that<br>> > lands up being the route taken they would \
probably only need to reserve<br>> > a namespace.<br>> <br>> I don't see \
why we couldn't embed XML. The point about Base64-encoding<br>> in RFC 3920 is \
that if you have XML character data that's content of the<br>> <auth/> \
element, it needs to be Base64-encoded. But for different<br>> authentication \
mechanisms we might define more elaborate approaches.<div><br></div><div>The real \
cracker is you can do far more with WSF than just plain-old authentication. You can \
pass the user identity around etc. but I guess that's another problem for another \
day.</div><div><br>> Unfortunately that might mean that the <auth/>, \
<challenge/>, and<br>> <response/> elements end up having a mixed \
content model (ick), like this:<br>> <br>> R: \
<stream:features><br>> <mechanisms \
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><br>> \
<mechanism>EXTERNAL</mechanism><br>> \
<mechanism>FOOBAR</mechanism><br>> </mechanisms><br>> \
</stream:features><br>> <br>> I: <auth \
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'<br>> \
mechanism='FOOBAR'><br>> <some-xml-here/><br>> \
</auth><br>> <br>> /psa<br>> <br><div><br></div><div>Icky was what I \
thought initially as well; however it shouldn't affect systems which don't support \
WSF mechanisms because they would never select them. I think this is the cleanest way \
to do it (without resorting to even more icky base-64 encoding \
XML).</div><div><br></div><div>I will experiment and see what I come up with. Thanks \
for the feedback.</div><div><br></div><div>Slightly off topic of the XML issue - we \
should maybe reserve/standardize Bare JID/Full JID claims with OASIS.</div><div><br \
style="text-indent: 0in !important; ">-- </div><div>Jonathan Dickinson<br \
style="text-indent: 0in !important; "></div></div> <br /><hr />Hotmail: \
Powerful Free email with security by Microsoft. <a \
href='https://signup.live.com/signup.aspx?id=60969' target='_new'>Get it \
now.</a></body> </html>
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe@jabber.org
_______________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic