RE: [Discussion] New REST Service Interfaces - Entitlements
> -Original Message- > From: Fabio Martelli [mailto:fabio.marte...@gmail.com] > Sent: Freitag, 18. Januar 2013 10:25 > To: dev@syncope.apache.org > Subject: Re: [Discussion] New REST Service Interfaces - Entitlements > > > Il giorno 18/gen/2013, alle ore 09.47, Jan Bernhardt ha scritto: > > >>> > >>> May be a rule or a validity date or something like this. > >>> I'll keep the possibility to extend EntitlementTO. > >> > >> A validity date would not be necessary. It is only important to tell > >> the unmarshaller to be LAX with the received document. By this the > >> ummarshaller will only unmarshall elements he can map to a given > >> Class attribute and ignore the rest. This gives us the possibility to > >> introduce new elements handled by new consumers and ignored by old > >> consumers. Thus not breaking anything. > > > > I guess at some point we should start using namespaces for our > > transfer objects. This would be needed latest, when we do not just add > > an element but start to rename / restructure elements... Since > > Namespaces are usually a little harder to handle, I would be happy to > > avoid using namespaces, until is really becomes necessary ;-) > > May be there was a misunderstanding. > I reported the validity date as a sample data that could be added to the > entitlement data set. > This 2validity date" can be used by the an access management service to > validate the entitlement (think about a temporary delegation). Ah, OK. That would be a nice example for a future extension.
Re: [Discussion] New REST Service Interfaces - Entitlements
Il giorno 18/gen/2013, alle ore 09.47, Jan Bernhardt ha scritto: >>> >>> May be a rule or a validity date or something like this. >>> I'll keep the possibility to extend EntitlementTO. >> >> A validity date would not be necessary. It is only important to tell the >> unmarshaller to be LAX with the received document. By this the >> ummarshaller will only unmarshall elements he can map to a given Class >> attribute and ignore the rest. This gives us the possibility to introduce new >> elements handled by new consumers and ignored by old consumers. Thus >> not breaking anything. > > I guess at some point we should start using namespaces for our transfer > objects. This would be needed latest, when we do not just add an element but > start to rename / restructure elements... Since Namespaces are usually a > little harder to handle, I would be happy to avoid using namespaces, until is > really becomes necessary ;-) May be there was a misunderstanding. I reported the validity date as a sample data that could be added to the entitlement data set. This 2validity date" can be used by the an access management service to validate the entitlement (think about a temporary delegation).
Re: [Discussion] New REST Service Interfaces - Entitlements
Il giorno 18/gen/2013, alle ore 09.21, Jan Bernhardt ha scritto: > Hi Fabio, > >>> >>> === Renaming Service === >>> Rename AuthenticationController to EntitlementService(Impl), since >> containing methods have little to nothing to do with authentication. It is >> only >> about Entitlements... >> >> Why not AuthorizationController or AccessController? I'd prefer the first >> one. >> May be this controller will be improved to add access controller features int >> the next future (please, take a look at the roadmap). > > I just took a look at the roadmap, and as far as I understand, authorization > features mentioned there are all about handling ENTITLEMENTS for different > realms and avoiding duplicates. REST based services are focusing on resources > and not processes. Authorization or AccessControl describes a process, > whereas Entitlement is the actual resource needed for Authorization > decisions. Let me give you an example. Authorization Services usually provide > a method like "user.hasRole(admin)" in RESTful design this would be mapped to > asking for an existing resource: Like > http://loclahost:9080/entitlements/users/4711/entitlements/admin if user with > id 4711 has role admin the response would be 200 OK (maybe with entitlement > object in response body). If user does not have the role admin, response code > would be 404 NOT FOUND, hence the caller would know that user 4711 is not > authorized. > > From this perspective, do you agree with me? Actually, not. In an AM scenario, the caller shouldn't know that a certain profile is authorized if and only if it has a certain role. This should be handled by the Access Manager. Usually the caller ask for authorization to access to a certain resource; the access manager search against entitlements/access policies and give back an answer. This is the reason why I'd suggest to use the prefix Authorization. Of course, I think that this controller could also expose methods for entitlement retrieving to be used by an administration console. Regards, F.
RE: [Discussion] New REST Service Interfaces - Entitlements
> Names will be Consistent. New CXF REST Services will all End with *Service. > Old Spring Services currently ending with *Controller will eventually all > vanish, once new Services are actually used (migration is complete). Than is absolutely OK for me. + 1. Andrei. > > Best regards. > Jan
Re: [Discussion] New REST Service Interfaces - Entitlements
I would rather do it in the annotations. Internally we often have a internal class without TO and a transfer object that ends in TO. So I think it makes sense to differentiate them on the class level. Christian On 18.01.2013 09:51, Jan Bernhardt wrote: >> Btw. I would rather name the xml element Entitlement than EntitlementTO >> as the fact that it is a transfer object is not important on the xml level. >> > I agree. Not using *TO ending would look nicer on transport layer. > The question here is, should we also remove "TO" in Classnames, or just set a > name in annotation, e.g. @XMLRootElement(name = "entitlement") ? > >> Christian
RE: [Discussion] New REST Service Interfaces - Entitlements
> > Btw. I would rather name the xml element Entitlement than EntitlementTO > as the fact that it is a transfer object is not important on the xml level. > I agree. Not using *TO ending would look nicer on transport layer. The question here is, should we also remove "TO" in Classnames, or just set a name in annotation, e.g. @XMLRootElement(name = "entitlement") ? > Christian
RE: [Discussion] New REST Service Interfaces - Entitlements
> > > > May be a rule or a validity date or something like this. > > I'll keep the possibility to extend EntitlementTO. > > A validity date would not be necessary. It is only important to tell the > unmarshaller to be LAX with the received document. By this the > ummarshaller will only unmarshall elements he can map to a given Class > attribute and ignore the rest. This gives us the possibility to introduce new > elements handled by new consumers and ignored by old consumers. Thus > not breaking anything. I guess at some point we should start using namespaces for our transfer objects. This would be needed latest, when we do not just add an element but start to rename / restructure elements... Since Namespaces are usually a little harder to handle, I would be happy to avoid using namespaces, until is really becomes necessary ;-) > > Regards. > Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
> >>> > >>> Option 1 matches more or less current marshaling. I personally would > prefer Option 2 because this would give us the opportunity to easily extend > EntitlementTO at a later point (if needed) without becoming incompatible > with previous version. > >> Agree with you for the reason given above. > > Not sure about this one as I do not know how probable it is that we > > have more attributes in Entitlement. > > May be a rule or a validity date or something like this. > I'll keep the possibility to extend EntitlementTO. A validity date would not be necessary. It is only important to tell the unmarshaller to be LAX with the received document. By this the ummarshaller will only unmarshall elements he can map to a given Class attribute and ignore the rest. This gives us the possibility to introduce new elements handled by new consumers and ignored by old consumers. Thus not breaking anything. Regards. Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Christian, > >> === Renaming Service === > >> Rename AuthenticationController to EntitlementService(Impl), since > containing methods have little to nothing to do with authentication. It is > only > about Entitlements... > > Why not AuthorizationController or AccessController? I'd prefer the first > one. > > May be this controller will be improved to add access controller features > > int > the next future (please, take a look at the roadmap). > > I agree with the names Fabio proposed. If it is planned to put more > Authorization stuff in there then it makes sense to not have Entitlement in > the name. Please take a look at my response to Fabio. RESTfull Services are about handling Resources and not Processes. Hence Entitlement would be a better match. > Like Andrei proposed we should either rename all controllers to Service or > none. If we rename them partly people will be confused. Of course names should be consistent. But as I already responded to Andrei, old REST Services ending with *Controller will not be renamed but eventually be removed. New Service Interfaces will all end with *Service and thus naming will be consistent. Best regards. Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Andrei, > > > === Renaming Service === > > Rename AuthenticationController to EntitlementService(Impl), since > > containing methods have little to nothing to do with authentication. > > It is only about Entitlements... > > +1 for Entitlement, -1 for Service. I would keep names consistently, if use > EntitlementService name, than rename all controllers to services inclusive > package name (but I suggest to do it on the later phase). Names will be Consistent. New CXF REST Services will all End with *Service. Old Spring Services currently ending with *Controller will eventually all vanish, once new Services are actually used (migration is complete). Best regards. Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Fabio, > > > > === Renaming Service === > > Rename AuthenticationController to EntitlementService(Impl), since > containing methods have little to nothing to do with authentication. It is > only > about Entitlements... > > Why not AuthorizationController or AccessController? I'd prefer the first one. > May be this controller will be improved to add access controller features int > the next future (please, take a look at the roadmap). I just took a look at the roadmap, and as far as I understand, authorization features mentioned there are all about handling ENTITLEMENTS for different realms and avoiding duplicates. REST based services are focusing on resources and not processes. Authorization or AccessControl describes a process, whereas Entitlement is the actual resource needed for Authorization decisions. Let me give you an example. Authorization Services usually provide a method like "user.hasRole(admin)" in RESTful design this would be mapped to asking for an existing resource: Like http://loclahost:9080/entitlements/users/4711/entitlements/admin if user with id 4711 has role admin the response would be 200 OK (maybe with entitlement object in response body). If user does not have the role admin, response code would be 404 NOT FOUND, hence the caller would know that user 4711 is not authorized. >From this perspective, do you agree with me? Best regards. Jan
Re: [Discussion] New REST Service Interfaces - Entitlements
Il giorno 17/gen/2013, alle ore 17.09, Christian Schneider ha scritto: > On 17.01.2013 14:43, Fabio Martelli wrote: >> Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: >> >>> Hi Syncoper, >>> >>> The following changes are proposed regarding AuthenticationController: >>> >>> === Renaming Service === >>> Rename AuthenticationController to EntitlementService(Impl), since >>> containing methods have little to nothing to do with authentication. It is >>> only about Entitlements... >> Why not AuthorizationController or AccessController? I'd prefer the first >> one. >> May be this controller will be improved to add access controller features >> int the next future (please, take a look at the roadmap). > I agree with the names Fabio proposed. If it is planned to put more > Authorization stuff in there then it makes sense to not have Entitlement > in the name. > Like Andrei proposed we should either rename all controllers to Service > or none. If we rename them partly people will be confused. > >>> === Changing response Type === >>> listEntitlements() returns a List whereas getEntitlements() returns >>> a Set. >>> >>> From my point of view both methods should return a SET since entitlements >>> have no order and cannot exists or be assigned more than once. >> Agree > I also agree with Set. >> >>> Due to some JAX-B / JAX-RS limitations, it is not possible to return a >>> collection with primitive data types in java. A wrapper class is required, >>> e.g. Set. >>> >>> EntitlementTO can be modeled in one of two ways: >>> >>> Option 1: >>> >>> ROLE_ADMIN >>> ROLE_SUPERUSER >>> >>> >>> Option 2: >>> >>> >>> ROLE_ADMIN >>> >>> >>> ROLE_SUPERUSER >>> >>> >>> >>> Option 1 matches more or less current marshaling. I personally would prefer >>> Option 2 because this would give us the opportunity to easily extend >>> EntitlementTO at a later point (if needed) without becoming incompatible >>> with previous version. >> Agree with you for the reason given above. > Not sure about this one as I do not know how probable it is that we have > more attributes in Entitlement. May be a rule or a validity date or something like this. I'll keep the possibility to extend EntitlementTO. > Btw. I would rather name the xml element Entitlement than EntitlementTO > as the fact that it is a transfer object is not important on the xml level. > > Christian > >> >>> WDYT? >>> >>> All of these changes will not apply to current Spring Controller/Services, >>> but only future CXF REST Service. So AuthenticationController will not be >>> renamed now, and responsetype of AuthenticationController will not change. >>> Changes only apply for new Service Interface and (Proxy) Implementation. >> Good. >> >> Regards, >> F. >> >
Re: [Discussion] New REST Service Interfaces - Entitlements
On 17.01.2013 14:43, Fabio Martelli wrote: > Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: > >> Hi Syncoper, >> >> The following changes are proposed regarding AuthenticationController: >> >> === Renaming Service === >> Rename AuthenticationController to EntitlementService(Impl), since >> containing methods have little to nothing to do with authentication. It is >> only about Entitlements... > Why not AuthorizationController or AccessController? I'd prefer the first one. > May be this controller will be improved to add access controller features int > the next future (please, take a look at the roadmap). I agree with the names Fabio proposed. If it is planned to put more Authorization stuff in there then it makes sense to not have Entitlement in the name. Like Andrei proposed we should either rename all controllers to Service or none. If we rename them partly people will be confused. >> === Changing response Type === >> listEntitlements() returns a List whereas getEntitlements() returns >> a Set. >> >> From my point of view both methods should return a SET since entitlements >> have no order and cannot exists or be assigned more than once. > Agree I also agree with Set. > >> Due to some JAX-B / JAX-RS limitations, it is not possible to return a >> collection with primitive data types in java. A wrapper class is required, >> e.g. Set. >> >> EntitlementTO can be modeled in one of two ways: >> >> Option 1: >> >> ROLE_ADMIN >> ROLE_SUPERUSER >> >> >> Option 2: >> >> >> ROLE_ADMIN >> >> >> ROLE_SUPERUSER >> >> >> >> Option 1 matches more or less current marshaling. I personally would prefer >> Option 2 because this would give us the opportunity to easily extend >> EntitlementTO at a later point (if needed) without becoming incompatible >> with previous version. > Agree with you for the reason given above. Not sure about this one as I do not know how probable it is that we have more attributes in Entitlement. Btw. I would rather name the xml element Entitlement than EntitlementTO as the fact that it is a transfer object is not important on the xml level. Christian > >> WDYT? >> >> All of these changes will not apply to current Spring Controller/Services, >> but only future CXF REST Service. So AuthenticationController will not be >> renamed now, and responsetype of AuthenticationController will not change. >> Changes only apply for new Service Interface and (Proxy) Implementation. > Good. > > Regards, > F. >
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Jan, > === Renaming Service === > Rename AuthenticationController to EntitlementService(Impl), since > containing methods have little to nothing to do with authentication. It is > only > about Entitlements... +1 for Entitlement, -1 for Service. I would keep names consistently, if use EntitlementService name, than rename all controllers to services inclusive package name (but I suggest to do it on the later phase). > > === Changing response Type === > listEntitlements() returns a List whereas getEntitlements() returns a > Set. > > Option 1: > >ROLE_ADMIN >ROLE_SUPERUSER > > > Option 2: > > > ROLE_ADMIN > > >ROLE_SUPERUSER > > +1 for Option 2 > And what I forgott to mention: listEntitlements and getEntitlements are not > very self-explanatory. A better name would be getAllEntitlements and > getMyEntitlements. +1 Cheers, Andrei.
Re: [Discussion] New REST Service Interfaces - Entitlements
Il giorno 17/gen/2013, alle ore 14.03, Jan Bernhardt ha scritto: > Hi Syncoper, > > The following changes are proposed regarding AuthenticationController: > > === Renaming Service === > Rename AuthenticationController to EntitlementService(Impl), since containing > methods have little to nothing to do with authentication. It is only about > Entitlements... Why not AuthorizationController or AccessController? I'd prefer the first one. May be this controller will be improved to add access controller features int the next future (please, take a look at the roadmap). > === Changing response Type === > listEntitlements() returns a List whereas getEntitlements() returns a > Set. > > From my point of view both methods should return a SET since entitlements > have no order and cannot exists or be assigned more than once. Agree > Due to some JAX-B / JAX-RS limitations, it is not possible to return a > collection with primitive data types in java. A wrapper class is required, > e.g. Set. > > EntitlementTO can be modeled in one of two ways: > > Option 1: > > ROLE_ADMIN > ROLE_SUPERUSER > > > Option 2: > > > ROLE_ADMIN > > > ROLE_SUPERUSER > > > > Option 1 matches more or less current marshaling. I personally would prefer > Option 2 because this would give us the opportunity to easily extend > EntitlementTO at a later point (if needed) without becoming incompatible with > previous version. Agree with you for the reason given above. > > WDYT? > > All of these changes will not apply to current Spring Controller/Services, > but only future CXF REST Service. So AuthenticationController will not be > renamed now, and responsetype of AuthenticationController will not change. > Changes only apply for new Service Interface and (Proxy) Implementation. Good. Regards, F.
RE: [Discussion] New REST Service Interfaces - Entitlements
And what I forgott to mention: listEntitlements and getEntitlements are not very self-explanatory. A better name would be getAllEntitlements and getMyEntitlements. Regards. Jan > -Original Message- > From: Jan Bernhardt [mailto:jbernha...@talend.com] > Sent: Donnerstag, 17. Januar 2013 14:04 > To: dev@syncope.apache.org > Subject: RE: [Discussion] New REST Service Interfaces - Entitlements > > Hi Syncoper, > > The following changes are proposed regarding AuthenticationController: > > === Renaming Service === > Rename AuthenticationController to EntitlementService(Impl), since > containing methods have little to nothing to do with authentication. It is > only > about Entitlements... > > === Changing response Type === > listEntitlements() returns a List whereas getEntitlements() returns a > Set. > > From my point of view both methods should return a SET since entitlements > have no order and cannot exists or be assigned more than once. > > Due to some JAX-B / JAX-RS limitations, it is not possible to return a > collection > with primitive data types in java. A wrapper class is required, e.g. > Set. > > EntitlementTO can be modeled in one of two ways: > > Option 1: > >ROLE_ADMIN >ROLE_SUPERUSER > > > Option 2: > > > ROLE_ADMIN > > >ROLE_SUPERUSER > > > > Option 1 matches more or less current marshaling. I personally would prefer > Option 2 because this would give us the opportunity to easily extend > EntitlementTO at a later point (if needed) without becoming incompatible > with previous version. > > WDYT? > > All of these changes will not apply to current Spring Controller/Services, but > only future CXF REST Service. So AuthenticationController will not be > renamed now, and responsetype of AuthenticationController will not > change. Changes only apply for new Service Interface and (Proxy) > Implementation. > > Best regards. > Jan
RE: [Discussion] New REST Service Interfaces - Entitlements
Hi Syncoper, The following changes are proposed regarding AuthenticationController: === Renaming Service === Rename AuthenticationController to EntitlementService(Impl), since containing methods have little to nothing to do with authentication. It is only about Entitlements... === Changing response Type === listEntitlements() returns a List whereas getEntitlements() returns a Set. >From my point of view both methods should return a SET since entitlements have >no order and cannot exists or be assigned more than once. Due to some JAX-B / JAX-RS limitations, it is not possible to return a collection with primitive data types in java. A wrapper class is required, e.g. Set. EntitlementTO can be modeled in one of two ways: Option 1: ROLE_ADMIN ROLE_SUPERUSER Option 2: ROLE_ADMIN ROLE_SUPERUSER Option 1 matches more or less current marshaling. I personally would prefer Option 2 because this would give us the opportunity to easily extend EntitlementTO at a later point (if needed) without becoming incompatible with previous version. WDYT? All of these changes will not apply to current Spring Controller/Services, but only future CXF REST Service. So AuthenticationController will not be renamed now, and responsetype of AuthenticationController will not change. Changes only apply for new Service Interface and (Proxy) Implementation. Best regards. Jan
