On 31/01/2017 18:03, Colm O hEigeartaigh wrote:
Hi Francesco,
On Thu, Jan 26, 2017 at 8:06 AM, Francesco Chicchiriccò <ilgro...@apache.org>
wrote:
About the definition of the new Application and Privilege (and their
relationship with existing User and Group, for example), however, these
will still require new JPA entities to be defined for internal storage, new
TO and ultimately something for Admin UI management.
I'm wondering how (or if) the concept of roles fits into this scenario of
Applications and Privileges? The problem for us is that the existing
entitlements/roles concepts in Syncope seems to map perfectly to that of
SCIM, along the lines of:
https://groups.google.com/forum/#!msg/cloud-directory/fs6szjVrBBA/tt3t0PZg0UEJ
It's not really clear to me why we can't re-use the existing concepts to
model entitlements/roles external to Syncope? Will there be a way to group
privileges similar to the way that roles group entitlements?
I have read with interest the link above.
I agree that the existing Roles in Syncope are fine to map that concept;
the problem I see to assimilate the existing Entitlements with the new
entities being discussed so far in this thread, e.g. Privileges and
Applications.
Entitlements are a pre-defined set of strings (which can also be
extended, as we see in the Camel Provisioning Manager), specifically
targeted to implement delegated administration, e.g. only for internal
purpose.
Privileges could be instead used to model the rights on a given
Application; please note that the former might depend on the latter,
e.g. "POST on /a/b/c" but also "Administer printers".
Summarizing: while Roles currently have only Entitlements associated, in
the future we might also associate Privileges (which in turn are related
to Applications) to them. As a result, user U with role R will own both
Entitlements and Privileges.
If "privilege" is not suitable as name, let's then rename the existing
Entitlements to something else and use the word "entitlement" to model
the new concept instead.
Finally, I want to let you know that I am quite advanced in building a
prototype - which could be likely delivered in a month or two - that
introduces Digest Authentication and JWT token management in Syncope 2.0.X
(you might want to ask Sergey about my stressful questions around these
points in CXF...).
Cool, are you referring to being able to perform authentication in Syncope
with a signed JWT token here or something else?
The idea is that the first invocation of a specific REST endpoint will
be used only for authentication (which will be set by default to Digest
Authentication, but could be any other mechanism including SAML 2.0, for
example); such call will return a signed JWT token, which could be used
for subsequent calls. Refresh and ban / blacklist mechanism will be also
provided.
I have found such approach being reported as REST best practice.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
