11:12 a.m.
Patch 159:
Add service to generate and retrieve a shared secret
A new REST service has been added to the TKS to manage shared secrets.
The shared secret is tied to the TKS-TPS connector, and is created at the
end of the TPS configuration. At this point, the TPS contacts the TKS and
requests that the shared secret be generated. The secret is returned to the
TPS, wrapped using the subsystem certificate of the TPS.
The TPS should then decrypt the shared secret and store it in its certificate
database. This operations requires JSS changes, though, and so will be deferred
to a later patch. For now, though, if the TPS and TKS share the same certdb, then
it is sufficient to generate the shared secret.
Clients and CLI are also provided. The CLI in particular is used to remove the
TPSConnector entries and the shared secret when the TPS is pkidestroyed.
Note: Patch 159 does have some code to remove the connector and shared
secret on pkidestroy. This code works fine, but I plan to refactor it
in a subsequent patch.
Specifically, I plan to write an old legacy style servlet
(DeregisterSystem.java) that will perform the operations needed to
deregister a system. For instance, for a TPS deregistering on a TKS,
the TKS needs to remove the TPS system user and remove the shared
secret. For a TPS deregistering from a KRA, the system user needs to be
removed. For a KRA deregistering from a CA, the system user and KRA
connector needs to be removed.
Why an old style legacy server? Because the new REST servlets do not as
yet support token auth as an authentication mechanism, and to be able to
support older legacy systems which do not have REST.
Patch 160:
Modify TKS self tests and execution to use new shared secret names
The self tests and TokenServlet are modified to use the new shared secret
names. A parameter has been added to allow legacy systems to continue running
as-is. With a new system, the TKS self test will not fail on startup if
no shared secret keys are configured. It will fail, however, if the keys are
configured, but the ComputeSessionKey operation fails.
9:04 p.m.
On 9/26/2013 11:12 AM, Ade Lee wrote:
Patch 159:
Add service to generate and retrieve a shared secret
A new REST service has been added to the TKS to manage shared secrets.
The shared secret is tied to the TKS-TPS connector, and is created at the
end of the TPS configuration. At this point, the TPS contacts the TKS and
requests that the shared secret be generated. The secret is returned to the
TPS, wrapped using the subsystem certificate of the TPS.
The TPS should then decrypt the shared secret and store it in its certificate
database. This operations requires JSS changes, though, and so will be deferred
to a later patch. For now, though, if the TPS and TKS share the same certdb, then
it is sufficient to generate the shared secret.
Clients and CLI are also provided. The CLI in particular is used to remove the
TPSConnector entries and the shared secret when the TPS is pkidestroyed.
In addition to the things that were discussed over IRC earlier I have
some comments:
1. The createConnector() probably should return HTTP 201 since it's
creating a new entry. This would be consistent with other resources.
2. The capitalization of "connector" in the help message is not consistent:
tks-tpsconnector TPS Connector management commands
tks-tpsconnector-add Add TPS Connector to TKS
tks-tpsconnector-find Find TPS connector details on TKS
tks-tpsconnector-del Remove TPS connector from TKS
3. The tks-tpsconnector-find output should have a header and footer like
other *-find commands:
----------------------
1 connector(s) matched
----------------------
Connector ID: 0
Host: server.example.com
Port: 8443
User ID: TPS-server.example.com-8443
Nickname: TPS-server.example.com-8443 sharedSecret
----------------------------
Number of entries returned 1
----------------------------
4. Currently the access to the connector is limited to the subsystem
user, which doesn't correspond to a real person. It should allow the TKS
administrator to add/delete the connectors. This can be done by checking
the principal.getRoles() in validateUser().
5. The tks-tpsconnector-add/del parameters right now are passed as
arguments. It probably should be passed using options because it may
change in the future:
tks-tpsconnector-add --host <host> --port <port>
tks-tpsconnector-del --connector-id <connector ID>
6. We discussed about changing the error code for non-existent entries
to 204 (https://fedorahosted.org/pki/ticket/746). However, now I think
404 actually makes more sense. See
http://stackoverflow.com/questions/11746894/what-is-the-proper-rest-respo....
Both of the following URL's should return the same error code because
the client shouldn't need to know which path is mapped to REST method:
* /rest/users/wronguser
* /rest/wrongpath
So methods like deleteConnector(), deleteSharedSecret(), etc. should
throw ResourceNotFoundException instead of returning silently if the
entry doesn't exist.
I'll continue the review tomorrow.
--
Endi S. Dewata
1:36 p.m.
OK - I added a new patch to address the comments below and do some
cleanup.
Please apply on top of the 159 and 160.
Ade
On Thu, 2013-09-26 at 21:04 -0500, Endi Sukma Dewata wrote:
On 9/26/2013 11:12 AM, Ade Lee wrote:
> Patch 159:
>
> Add service to generate and retrieve a shared secret
>
> A new REST service has been added to the TKS to manage shared secrets.
> The shared secret is tied to the TKS-TPS connector, and is created at the
> end of the TPS configuration. At this point, the TPS contacts the TKS and
> requests that the shared secret be generated. The secret is returned to the
> TPS, wrapped using the subsystem certificate of the TPS.
>
> The TPS should then decrypt the shared secret and store it in its certificate
> database. This operations requires JSS changes, though, and so will be
deferred
> to a later patch. For now, though, if the TPS and TKS share the same certdb,
then
> it is sufficient to generate the shared secret.
>
> Clients and CLI are also provided. The CLI in particular is used to remove
the
> TPSConnector entries and the shared secret when the TPS is pkidestroyed.
In addition to the things that were discussed over IRC earlier I have
some comments:
1. The createConnector() probably should return HTTP 201 since it's
creating a new entry. This would be consistent with other resources.
2. The capitalization of "connector" in the help message is not consistent:
tks-tpsconnector TPS Connector management commands
tks-tpsconnector-add Add TPS Connector to TKS
tks-tpsconnector-find Find TPS connector details on TKS
tks-tpsconnector-del Remove TPS connector from TKS
3. The tks-tpsconnector-find output should have a header and footer like
other *-find commands:
----------------------
1 connector(s) matched
----------------------
Connector ID: 0
Host: server.example.com
Port: 8443
User ID: TPS-server.example.com-8443
Nickname: TPS-server.example.com-8443 sharedSecret
----------------------------
Number of entries returned 1
----------------------------
4. Currently the access to the connector is limited to the subsystem
user, which doesn't correspond to a real person. It should allow the TKS
administrator to add/delete the connectors. This can be done by checking
the principal.getRoles() in validateUser().
5. The tks-tpsconnector-add/del parameters right now are passed as
arguments. It probably should be passed using options because it may
change in the future:
tks-tpsconnector-add --host <host> --port <port>
tks-tpsconnector-del --connector-id <connector ID>
6. We discussed about changing the error code for non-existent entries
to 204 (https://fedorahosted.org/pki/ticket/746). However, now I think
404 actually makes more sense. See
http://stackoverflow.com/questions/11746894/what-is-the-proper-rest-respo....
Both of the following URL's should return the same error code because
the client shouldn't need to know which path is mapped to REST method:
* /rest/users/wronguser
* /rest/wrongpath
So methods like deleteConnector(), deleteSharedSecret(), etc. should
throw ResourceNotFoundException instead of returning silently if the
entry doesn't exist.
I'll continue the review tomorrow.
10:52 a.m.
Based on revire comments and ack from Endi and Jack, I will push 159,
160 and 161.
Attaching 162 to add a modify option and add ability for a tks admin to
remove a connector.
Please review.
Thanks, Ade
On Fri, 2013-09-27 at 14:36 -0400, Ade Lee wrote:
OK - I added a new patch to address the comments below and do some
cleanup.
Please apply on top of the 159 and 160.
Ade
On Thu, 2013-09-26 at 21:04 -0500, Endi Sukma Dewata wrote:
> On 9/26/2013 11:12 AM, Ade Lee wrote:
> > Patch 159:
> >
> > Add service to generate and retrieve a shared secret
> >
> > A new REST service has been added to the TKS to manage shared secrets.
> > The shared secret is tied to the TKS-TPS connector, and is created at the
> > end of the TPS configuration. At this point, the TPS contacts the TKS
and
> > requests that the shared secret be generated. The secret is returned to
the
> > TPS, wrapped using the subsystem certificate of the TPS.
> >
> > The TPS should then decrypt the shared secret and store it in its
certificate
> > database. This operations requires JSS changes, though, and so will be
deferred
> > to a later patch. For now, though, if the TPS and TKS share the same
certdb, then
> > it is sufficient to generate the shared secret.
> >
> > Clients and CLI are also provided. The CLI in particular is used to
remove the
> > TPSConnector entries and the shared secret when the TPS is pkidestroyed.
>
> In addition to the things that were discussed over IRC earlier I have
> some comments:
>
> 1. The createConnector() probably should return HTTP 201 since it's
> creating a new entry. This would be consistent with other resources.
>
> 2. The capitalization of "connector" in the help message is not
consistent:
>
> tks-tpsconnector TPS Connector management commands
> tks-tpsconnector-add Add TPS Connector to TKS
> tks-tpsconnector-find Find TPS connector details on TKS
> tks-tpsconnector-del Remove TPS connector from TKS
>
> 3. The tks-tpsconnector-find output should have a header and footer like
> other *-find commands:
>
> ----------------------
> 1 connector(s) matched
> ----------------------
> Connector ID: 0
> Host: server.example.com
> Port: 8443
> User ID: TPS-server.example.com-8443
> Nickname: TPS-server.example.com-8443 sharedSecret
> ----------------------------
> Number of entries returned 1
> ----------------------------
>
> 4. Currently the access to the connector is limited to the subsystem
> user, which doesn't correspond to a real person. It should allow the TKS
> administrator to add/delete the connectors. This can be done by checking
> the principal.getRoles() in validateUser().
>
> 5. The tks-tpsconnector-add/del parameters right now are passed as
> arguments. It probably should be passed using options because it may
> change in the future:
>
> tks-tpsconnector-add --host <host> --port <port>
> tks-tpsconnector-del --connector-id <connector ID>
>
> 6. We discussed about changing the error code for non-existent entries
> to 204 (https://fedorahosted.org/pki/ticket/746). However, now I think
> 404 actually makes more sense. See
>
http://stackoverflow.com/questions/11746894/what-is-the-proper-rest-respo....
> Both of the following URL's should return the same error code because
> the client shouldn't need to know which path is mapped to REST method:
> * /rest/users/wronguser
> * /rest/wrongpath
>
> So methods like deleteConnector(), deleteSharedSecret(), etc. should
> throw ResourceNotFoundException instead of returning silently if the
> entry doesn't exist.
>
> I'll continue the review tomorrow.
>
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
11:26 a.m.
acked by Endi with a couple small changes. Nickname no longer permitted
to be modified, and attempt to modify nickname/userid results in
UnauthorizedException being thrown.
All pushed to master.
On Mon, 2013-09-30 at 11:52 -0400, Ade Lee wrote:
Based on revire comments and ack from Endi and Jack, I will push
159,
160 and 161.
Attaching 162 to add a modify option and add ability for a tks admin to
remove a connector.
Please review.
Thanks, Ade
On Fri, 2013-09-27 at 14:36 -0400, Ade Lee wrote:
> OK - I added a new patch to address the comments below and do some
> cleanup.
>
> Please apply on top of the 159 and 160.
>
> Ade
>
> On Thu, 2013-09-26 at 21:04 -0500, Endi Sukma Dewata wrote:
> > On 9/26/2013 11:12 AM, Ade Lee wrote:
> > > Patch 159:
> > >
> > > Add service to generate and retrieve a shared secret
> > >
> > > A new REST service has been added to the TKS to manage shared
secrets.
> > > The shared secret is tied to the TKS-TPS connector, and is created at
the
> > > end of the TPS configuration. At this point, the TPS contacts the
TKS and
> > > requests that the shared secret be generated. The secret is returned
to the
> > > TPS, wrapped using the subsystem certificate of the TPS.
> > >
> > > The TPS should then decrypt the shared secret and store it in its
certificate
> > > database. This operations requires JSS changes, though, and so will
be deferred
> > > to a later patch. For now, though, if the TPS and TKS share the same
certdb, then
> > > it is sufficient to generate the shared secret.
> > >
> > > Clients and CLI are also provided. The CLI in particular is used to
remove the
> > > TPSConnector entries and the shared secret when the TPS is
pkidestroyed.
> >
> > In addition to the things that were discussed over IRC earlier I have
> > some comments:
> >
> > 1. The createConnector() probably should return HTTP 201 since it's
> > creating a new entry. This would be consistent with other resources.
> >
> > 2. The capitalization of "connector" in the help message is not
consistent:
> >
> > tks-tpsconnector TPS Connector management commands
> > tks-tpsconnector-add Add TPS Connector to TKS
> > tks-tpsconnector-find Find TPS connector details on TKS
> > tks-tpsconnector-del Remove TPS connector from TKS
> >
> > 3. The tks-tpsconnector-find output should have a header and footer like
> > other *-find commands:
> >
> > ----------------------
> > 1 connector(s) matched
> > ----------------------
> > Connector ID: 0
> > Host: server.example.com
> > Port: 8443
> > User ID: TPS-server.example.com-8443
> > Nickname: TPS-server.example.com-8443 sharedSecret
> > ----------------------------
> > Number of entries returned 1
> > ----------------------------
> >
> > 4. Currently the access to the connector is limited to the subsystem
> > user, which doesn't correspond to a real person. It should allow the TKS
> > administrator to add/delete the connectors. This can be done by checking
> > the principal.getRoles() in validateUser().
> >
> > 5. The tks-tpsconnector-add/del parameters right now are passed as
> > arguments. It probably should be passed using options because it may
> > change in the future:
> >
> > tks-tpsconnector-add --host <host> --port <port>
> > tks-tpsconnector-del --connector-id <connector ID>
> >
> > 6. We discussed about changing the error code for non-existent entries
> > to 204 (https://fedorahosted.org/pki/ticket/746). However, now I think
> > 404 actually makes more sense. See
> >
http://stackoverflow.com/questions/11746894/what-is-the-proper-rest-respo....
> > Both of the following URL's should return the same error code because
> > the client shouldn't need to know which path is mapped to REST method:
> > * /rest/users/wronguser
> > * /rest/wrongpath
> >
> > So methods like deleteConnector(), deleteSharedSecret(), etc. should
> > throw ResourceNotFoundException instead of returning silently if the
> > entry doesn't exist.
> >
> > I'll continue the review tomorrow.
> >
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
_______________________________________________
Pki-devel mailing list
Pki-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
4100
days inactive
4104
days old
4 comments
2 participants
participants (2)
-
Ade Lee -
Endi Sukma Dewata