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:
<security-constraint>
<web-resource-collection>
<web-resource-name>Profiles</web-resource-name>
<url-pattern>/rest/profiles/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
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