See my responses below.
Le 27/11/2014 10:28, Hudalla Kai
(INST/ESY) a écrit :
Simon,
You
haven’t been able to see any handling of RPK etc because I
have not yet created a PR for it
J
I was talking about your user-principal-support
branch. I assumed it's not finished yet, but I would like to
know what it look like.
With
the Principal based API you would be able to determine the
type of authentication by means of the Principal object’s
concrete type, e.g. we could have a PSKPrincipal,
RPKPrincipal and an X509Principal.
Sounds good.
However,
what are the “different things you need to check” for these
different types of Principals? Is it not sufficient to be
able to get to the client’s identity (a String)?
Our first thought was to allow users to define how a
device(endpoint) should communicate with Leshan server.( I mean in
secure way or not)
if it choose a secure way, we should check after DTLS Handshake (at
lwm2m registration for now), if the DTLS identity matches with the
device endpoint.
So we must check,
1) if the device did the handshake with the security mode choosen by
the user
and
2) check the identity :
for psk, check if the identity is the same as the one set by the
user,
for rpk, check if the rpk is the same as the one set by the user,
for certificate, check if the identity is equals to the endpoint.
For Identity matching (2), we could easily find a way to work only
with Principals abstraction, but for security mode (1) matching, I
think we need to use the concrete type.
For Leshan, we need a way to get the
psk_identify, the RPK(Raw Public Key) or the certificate
linked to the DTLS session.
Currently, there is getter for psk_identity and
X509Certificate, I add a getter for the RawPublicKey on my
scandium fork.
So, your proposition sounds good.
I take a look at your code, but I don't see any RPK
management.
(Actually, I think the RPK API for scandium could be
improved, I'm working on it.)
For Leshan, we need to know if this is a RPK, PSK or
Certificate authentication. We does not check the same thing
in each case. How will I do that with the new "principal
API" ?
----------
Forwarded message ---------
From: Kovatsch Matthias <kovatsch@xxxxxxxxxxx>
Date: Sun Nov 09 2014 at 05:11:44
Subject: Re: [cf-dev] Access to authenticated client
identity
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
This
sounds great! The Scandium API definitely needs
improvement (rather creation :P).
The
general idea is again to stick as close as possible
to established APIs and make a “best of”: pick the
nicest solution available and only change them if
they are in some way inconvenient.
What
would be the best way to continue in general?
Add
the API features just as needed (e.g., by Leshan)
and then tweak them according to the feedback on the
mailing list?
Or
organize some kind of call and prepare a roadmap?
Ciao
Matthias
To: Californium (Cf) developer
discussions
Subject:
Re: [cf-dev] Access to authenticated client
identity
Exactly,
this would be manifested by the different types of
java.security.Principal representing these
different identity types.
Kai
Sounds
good,
I
suppose the identity would be the psk_identity
or the public key or the x509 certificate
depending of the ciphersuite used?
On
Fri Oct 24 2014 at 09:36:39 Hudalla Kai <Kai.Hudalla@xxxxxxxxxxxx>
wrote:
Hi,
I
would like to take another attempt at
introducing generic support for accessing
the identity of an authenticated client
within Californium
J
I
have seen that e.g. the leshan project
uses Scandium’s
DTLSConnector.getSessionByAddress()
operation to get at the underlying
DTLSSession for the client and then
retrieves the client’s PskIdentity using
DTLSSession.getPskIdentity(). This way,
the client code (leshan) is exposed to the
internal workings of the Californium stack
and also seems to need to know whether the
client has been authenticated by means of
PSK or a certificate.
What
I would like to propose instead is to
introduce an operation
org.eclipse.californium.core.coap.Request.getPrincipal()
for accessing the authenticated client’s
principal. Very much along the way the
Java Servlet API does it where
HttpServletRequest.getUserPrincipal() can
be used to access the authenticated user
prinicipal. This way, the client code
would never need to bother, how and where
the Principal was established for the CoAP
client but can simply focus on using the
identity.
I
have done some prove-of-concept work
around this approach involving some slight
modifications of a handful of classes from
element-connector, Scandium and
Californium.
What
do you think?
Regards,
Kai
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|
