opencadc / ac Goto Github PK

The ca.nrc.cadc.ac.client.GMSClient class in cadc-access-control always default to the CERT AuthMethod in each of its calls. This needs to be modified to allow Cookie access from the UI.

the abstract reader class uses LocalAuthority to mangle group URIs while reading docs; it should not need it at all and should just construct the group as transmitted... if full URIs are missing then doc format has to change.... I suggest changing the model to start using the GroupURI class if possible since it will help uncover the inconsistent use of "String group" which sometimes is a URI and sometimes just the name.

The GMSClient should have profiling log information.

The cookies generated by the login endpoint contain characters that are not accepted by the most recent versions of apache tomcat.

The workaround is to have tomcat use a legacy cookie processor by adding the following directive to context.xml:

<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />

In GMSClient.java the URI creation should be configurable.

Possible patch is to change the constructor:

public GMSClientMain()
{
    //client = new GMSClient(URI.create("ivo://oats.inaf.it/gms"));
    LocalAuthority localAuthority = new LocalAuthority();
    URI serviceURI = localAuthority.getServiceURI(Standards.GMS_GROUPS_01.toString());
    client = new GMSClient(URI.create(serviceURI.toString()));
}

they work for client-server authentication but this makes them not reusable on the server side (eg for a GMS call).

not sure that's actually a problem, but just noting it here so it isn't forgotten

It should support cookie access for UI requests made for User and Group Name Listings.

The cadc-access-control AuthenticationImplementation class drops to anonymous if no http account is returned from LDAP. This should check for an internal account instead.

This is needed by Skaha as it will pass it to the Job Creation.

Currently LdapConfig.java hard codes the LDAP config file name to "ac-ldap-config.properties". This way of hard coding the config file name should be replaced by a more flexible way to specify the name. This change can be implemented when we refactor the ac servlets.

As per JSON.org, numbers may not begin with a zero, but when listing users, some IDs begin with a zero, but are written out as a number datatype.

To reproduce within CADC:

Authenticated request to /ac/users/ with the Accept: application/json header set.
First returned value has identities/$/@type=HTTP numeric value that begins with zero.
The JSON parser in the browser fails to load this, and so we cannot make a proper CORS request.

The username, in this case, needs to be declared as a String.

The authenticator implementation should allow users with only a certificate to proceed with the auth type of CERT/TLS, rather than dropping them to anonymous.

When calling underlying apis from storage inventory the Authorization token is getting passed only when domain of the issuer of token is same as the calling api.
the logic to setAuthorization header is present in cadc-util (ca.nrc.cadc.net.HttpTransfer)

  for (String domain : next.getDomains()) { 
      if (conn.getURL().getHost().endsWith(domain)) {
      ...............
      }} 

Storage inventory can be deployed into different regions and the domain might be different for those regions , in this case Authorization token is not getting passed. This logic should be changed to accommodate all the domains.

even though it is not used

Currently when processing an account request and cadc-access-control-server finds a duplicate for the requested account, it returns an error message with specific account information. This results in user information leak. The following are examples of the returned error message:

user dn15985618998881 found in ou=userRequests,ou=ds,dc=canfar,dc=net

email address [email protected] for user dn215985619007211 found in ou=userRequests,ou=ds,dc=canfar,dc=net

GroupURI only checks that there is a scheme; doesn't care what it is

As per JSON.org, numbers may not begin with a zero, but when listing users, some IDs begin with a zero, but are written out as a number datatype.

To reproduce:

• Authenticated request to /ac/users/ with the Accept: application/json header set.
• First returned value has identities/$/@type=HTTP numeric value that begins with zero.

The JSON parser in the browser fails to load this, and so we cannot make a proper CORS request.

The redirect issued by the WhoAmIServlet always uses AuthMethod.CERT to lookup the URL. It should, instead, be using the same auth method with which the user connected so that clients can do automatic redirects.

The system property magic from forking registry client is opaque and inscrutable.