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
|