[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pki-devel] [PATCH]136 - initial framework for restful interfaces for managing profiles

On 7/19/2013 8:44 AM, Ade Lee wrote:
GET /profiles and then in the method itself determine whether or not I
have already logged in (I will have a principal) and return different
results accordingly.

Right now, that is not working.  The only way that I can guarantee that
client auth takes place and the credential is provided is by putting in
a security constraint that requires /profiles/* to use client
authentication.  But then, I cannot do GET /profiles without
authentication.  It seems clientAuth=want is not working.

Some comments:

1. It looks like the current clientAuth setting is fine, but the SSL authenticator needs to be configured to use session. See the alwaysUseSession parameter in this page: http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html. I posted patch #278 to add this parameter.

Then the security constraint can be configured without <auth-constraint> to allow anonymous access:


I've tested this with profile-find, it will return different number of results depending on the authentication. This way we won't need to use separate agent/admin interface.

2. For the profile-find output, I think it would be useful to show some basic info such as profile name and description in addition to the ID and URL.

3. The profile-show command stores the entire profile into an output file, it doesn't show anything to the screen. I think it would be useful and more consistent to show the profile summary such as id, name, description, input and output attribute names, URL. Then people can optionally specify --output download the entire file.

4. Does the profile subsystem support renaming a profile? The profile-mod may need to take 2 parameters: the old profile name and an input file containing the new profile name and the new attributes.

5. Some methods in ProfileService would catch and swallow the exception. It might be better for now to throw a generic exception or just don't catch at all. This way the client will know if there's an error. In the future we can revisit the code to throw more specific errors.

Endi S. Dewata

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]