9:21 a.m.
A new REST service and clients have been added to manage the profiles
in the TPS configuration file.
Ticket #652
--
Endi S. Dewata
12:01 a.m.
1. There is some code in ProfileModifyCLI that refers to changing the
status of the profile (enabled/ disabled) ie. an option that is read
in. However, that option value does not appear to be used in any way.
2. Profiles are unique in that - due to common criteria requirements,
profiles must be disabled by an agent before being changed by an admin.
Thats the meaning behind the target.agent_approve.list parameter.
So, there needs to be a call to enable/disable the profile, and this may
or may not have to be a call separate from modifyProfile() because the
authz/acls are different.
Also, there need to be checks to confirm that prior to any operation
that add/remove/modify the profile, the profile is disabled.
In fact, while only profiles are in the target.agent_approve.list, one
could choose to put any of the various elements in there, and so this
mechanism should be put in place generally.
Ade
On Tue, 2013-09-24 at 09:21 -0500, Endi Sukma Dewata wrote:
A new REST service and clients have been added to manage the
profiles
in the TPS configuration file.
Ticket #652
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
3:37 p.m.
New patch attached.
On 10/1/2013 12:01 AM, Ade Lee wrote:
1. There is some code in ProfileModifyCLI that refers to changing
the
status of the profile (enabled/ disabled) ie. an option that is read
in. However, that option value does not appear to be used in any way.
Fixed.
2. Profiles are unique in that - due to common criteria
requirements,
profiles must be disabled by an agent before being changed by an admin.
Thats the meaning behind the target.agent_approve.list parameter.
Fixed.
So, there needs to be a call to enable/disable the profile, and this
may
or may not have to be a call separate from modifyProfile() because the
authz/acls are different.
This is now handled by separate functions. The updateProfile() is used
by the admin to modify the profile configuration and submit it for
approval. The changeProfileStatus() is used by the agent to
approve/reject the changes or to enable/disable the profile after that.
If we do not want to require agent approval (by removing Profiles from
the approval list), the admin will be able to enable/disable the
profiles directly.
Also, there need to be checks to confirm that prior to any operation
that add/remove/modify the profile, the profile is disabled.
Fixed.
In fact, while only profiles are in the target.agent_approve.list,
one
could choose to put any of the various elements in there, and so this
mechanism should be put in place generally.
To generalize this function we will need to have separate update and
change status methods in each resource. Let's see if the current logic
in TPS profile is correct, then we can refactor it for reuse in other
resources.
--
Endi S. Dewata
10:54 a.m.
Attaching the correct patch.
--
Endi S. Dewata
On 10/24/2013 3:37 PM, Endi Sukma Dewata wrote:
New patch attached.
On 10/1/2013 12:01 AM, Ade Lee wrote:
> 1. There is some code in ProfileModifyCLI that refers to changing the
> status of the profile (enabled/ disabled) ie. an option that is read
> in. However, that option value does not appear to be used in any way.
Fixed.
> 2. Profiles are unique in that - due to common criteria requirements,
> profiles must be disabled by an agent before being changed by an admin.
> Thats the meaning behind the target.agent_approve.list parameter.
Fixed.
> So, there needs to be a call to enable/disable the profile, and this may
> or may not have to be a call separate from modifyProfile() because the
> authz/acls are different.
This is now handled by separate functions. The updateProfile() is used
by the admin to modify the profile configuration and submit it for
approval. The changeProfileStatus() is used by the agent to
approve/reject the changes or to enable/disable the profile after that.
If we do not want to require agent approval (by removing Profiles from
the approval list), the admin will be able to enable/disable the
profiles directly.
> Also, there need to be checks to confirm that prior to any operation
> that add/remove/modify the profile, the profile is disabled.
Fixed.
> In fact, while only profiles are in the target.agent_approve.list, one
> could choose to put any of the various elements in there, and so this
> mechanism should be put in place generally.
To generalize this function we will need to have separate update and
change status methods in each resource. Let's see if the current logic
in TPS profile is correct, then we can refactor it for reuse in other
resources.
4072
days inactive
4106
days old
3 comments
2 participants
participants (2)
-
Ade Lee -
Endi Sukma Dewata