We should move the connector to Java 8.

@tkrille already lists the steps which are need to be done to deploy releases to Bintray with CircleCI. The steps need to be adapt to the connector4java releases.

A trialing forward slash in the endpoint URL leads to some incorrect looking URLs. For example, this is a URL generated by OsiamConnector#getAuthorizationUri, if the auth-server endpoint is set to http://localhost:8080/osiam-server/:

http://localhost:8080/osiam-server//oauth/authorize?client_id=...

Note the double forward slashes in /osiam-server//oauth/authorize. Note also, that this is not causing erroneous behavior in any following-up component like Jersey client or the actual browser that follows these URLs.

When I use the retrieveAccessToken with the ResourceOwnerPasswordCredentials Grant type,
then I can't see, if the credentials are wrong, or if I have a technical error (e.g. osiam server not found). Always ConnectionInitializationException is thrown. I would expect something like a LoginException.

increase CONNECT_TIMEOUT and READ_TIMEOUT parameters

files:
src/main/java/org/osiam/client/AbstractOsiamService.java
src/main/java/org/osiam/client/AuthService.java

-    private static final int CONNECT_TIMEOUT = 2500;
-    private static final int READ_TIMEOUT = 5000;
+    private static final int CONNECT_TIMEOUT = 250000;
+    private static final int READ_TIMEOUT = 500000;

Hi, Can you guide me with the following error.

Exception in thread "main" org.osiam.client.exception.ConnectionInitializationException: Cannot connect to OSIAM
at org.osiam.client.AbstractOsiamService.createResource(AbstractOsiamService.java:193)
at org.osiam.client.OsiamUserService.createUser(OsiamUserService.java:127)
at org.osiam.client.OsiamConnector.createUser(OsiamConnector.java:445)
at osiam.CreateUser.main(CreateUser.java:124)
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Failed to instantiate class org.osiam.resources.helper.JsonDateSerializer, problem: null
at com.fasterxml.jackson.databind.SerializerProvider._createAndCacheUntypedSerializer(SerializerProvider.java:916)
at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:470)
at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.resolve(BeanSerializerBase.java:300)
at com.fasterxml.jackson.databind.ser.SerializerCache.addAndResolveNonTypedSerializer(SerializerCache.java:146)
at com.fasterxml.jackson.databind.SerializerProvider._createAndCacheUntypedSerializer(SerializerProvider.java:901)
at com.fasterxml.jackson.databind.SerializerProvider.findValueSerializer(SerializerProvider.java:429)
at com.fasterxml.jackson.databind.SerializerProvider.findTypedValueSerializer(SerializerProvider.java:520)
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializeValue(DefaultSerializerProvider.java:99)
at com.fasterxml.jackson.databind.ObjectMapper._configAndWriteValue(ObjectMapper.java:2626)
at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:2118)
at org.osiam.client.AbstractOsiamService.mapToString(AbstractOsiamService.java:280)
at org.osiam.client.AbstractOsiamService.createResource(AbstractOsiamService.java:191)
... 3 more
Caused by: java.lang.IllegalArgumentException: Failed to instantiate class org.osiam.resources.helper.JsonDateSerializer, problem: null
at com.fasterxml.jackson.databind.util.ClassUtil.throwAsIAE(ClassUtil.java:328)
at com.fasterxml.jackson.databind.util.ClassUtil.unwrapAndThrowAsIAE(ClassUtil.java:348)
at com.fasterxml.jackson.databind.util.ClassUtil.createInstance(ClassUtil.java:380)
at com.fasterxml.jackson.databind.ser.DefaultSerializerProvider.serializerInstance(DefaultSerializerProvider.java:426)
at com.fasterxml.jackson.databind.ser.BasicSerializerFactory.findSerializerFromAnnotation(BasicSerializerFactory.java:447)
at com.fasterxml.jackson.databind.ser.BeanSerializerFactory._constructWriter(BeanSerializerFactory.java:729)
at com.fasterxml.jackson.databind.ser.BeanSerializerFactory.findBeanProperties(BeanSerializerFactory.java:579)
at com.fasterxml.jackson.databind.ser.BeanSerializerFactory.constructBeanSerializer(BeanSerializerFactory.java:360)
at com.fasterxml.jackson.databind.ser.BeanSerializerFactory.findBeanSerializer(BeanSerializerFactory.java:247)
at com.fasterxml.jackson.databind.ser.BeanSerializerFactory.createSerializer(BeanSerializerFactory.java:198)
at com.fasterxml.jackson.databind.ser.SerializerFactory.createSerializer(SerializerFactory.java:53)
at com.fasterxml.jackson.databind.SerializerProvider._createUntypedSerializer(SerializerProvider.java:935)
at com.fasterxml.jackson.databind.SerializerProvider._createAndCacheUntypedSerializer(SerializerProvider.java:911)
... 14 more
Caused by: java.lang.ClassNotFoundException: org.joda.time.format.ISODateTimeFormat
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.osiam.resources.helper.JsonDateSerializer.(JsonDateSerializer.java:40)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.fasterxml.jackson.databind.util.ClassUtil.createInstance(ClassUtil.java:378)
... 24 more

I think we just need to follow the migration guide:
https://circleci.com/docs/2.0/migrating-from-1-2/

It's currently unclear whether the connector is completely thread safe. Someone should check this.

Deserialization fails, if the schemas attribute contains an extension schema, but no data is contained in the JSON object. The SCIM spec states under https://tools.ietf.org/html/rfc7643#section-3.3

Each value in the "schemas" attribute indicates additive schema that
MAY exist in a SCIM resource representation.

This means, that the presence of an extension schema in the schemas attribute, does not necessarily mean, that the current JSON object contains data for this extension. So, the restrictions of the user deserializer have to be loosened.

Hi, i receive the following error when i run the command

command

AccessToken at = osiamConnector.retrieveAccessToken(authcode);

Error

Exception in thread "main" org.osiam.client.exception.ConnectionInitializationException: Could not deserialize the error response for the HTTP status 'Found'. Original response:
at org.osiam.client.AuthService.checkAndHandleResponse(AuthService.java:513)
at org.osiam.client.AuthService.retrieveAccessToken(AuthService.java:189)
at org.osiam.client.OsiamConnector.retrieveAccessToken(OsiamConnector.java:429)
at osiam.CreateUser.main(CreateUser.java:122)

From @umerkayani:
In Vibesa we require a more efficient version of searchUsers method of connector4java component. Right now we have the method as follows:

public SCIMSearchResult<User> searchUsers(Query query, AccessToken accessToken)

and we need something like this:

public List<SCIMSearchResult<User>> searchUsers(List<Query> queries, AccessToken accessToken)

Moved from Jira.

Managing OAuth clients is currently not supported by the connector, but seems like a viable feature.

As discussed in osiam/addon-self-administration#180 (comment), the connector should be able to determine the version of the OSIAM server it is talking to, and based in this information, call the right endpoint.

We had some issues with outdated snapshot dependencies on CircleCI. I think we should use Maven with the -U switch.

The connector seems to reuse the same connection to the OSIAM auth- and resource server. This may lead to a performance bottleneck when multiple threads from the client application try to interact with Osiam. All other threads in the client have to wait until the connector is freed.

To ease the build and release process I suggest that we migrate the build process away from Maven to Gradle. I started to work on that in my fork, please feel free to have a look. We need to work out a release process with Gradle though. Does anybody have an idea?

At this time connect and read timeouts can only be configured application-global, but the ability to define timeouts on a per connector basis must also be existent.

Unfortunately, we need https://github.com/jersey/jersey/pull/121 to be merged as we cannot set these properties on the WebTarget, because of https://java.net/jira/browse/JERSEY-2378.

So, as soon as https://github.com/jersey/jersey/pull/121 is merged, we can implement this feature.

We are testing the OSIAM connector4java (v1.7) against an OSIAM Auth server mock deployed in a Resin 4 container (Mac OS X and CentOS), and we are getting a server error likely caused by the Jersey client usage by the OSIAM connector.

The error occurs because Resin doesn't allow POST requests without a Content-length header. To reproduce, deploy the auth server in Resin, and when invoking:

osiamConnector.revokeAccessToken(accessToken);

The server returns a HTTP 400 Bad request response:

POST requires content-length

POST requires content-length

Looking at the connector code, there are some methods ending Jersey client requests with .post(null);:

https://github.com/osiam/connector4java/blob/master/src/main/java/org/osiam/client/AuthService.java

This could be solved by merely changing null to an empty string. This would force Jersey client to set the required header with a zero value.

In our project we have many (round about 10,000) huge user data sets. They have many extension field values. We use the "searchUsers"-API to check if a user has access rights to specific parts of our software. So we have many rules. These rules are just search queries.

We have the feeling that the de-/serialization takes a lot of time. For example: if we use the searchUsers query directly against osiam (http-request) we got an answer in ~20sec. But if we use the searchUsers (same query, same parameters) against the connector4java we got an answer in ~30sec. For me it suggests that the deserialization took about ~10sec.

BTW: The query above delivered ~2,000 Users. But not the whole user data set! Only the externalId and userName.

@wallner already implemented this in the server, and it must now be implemented in the client, too.

Hi, i receive the following error when i run the command

command

AccessToken at = osiamConnector.retrieveAccessToken(authcode);

Error

Exception in thread "main" org.osiam.client.exception.ConnectionInitializationException: Could not deserialize the error response for the HTTP status 'Found'. Original response:
at org.osiam.client.AuthService.checkAndHandleResponse(AuthService.java:513)
at org.osiam.client.AuthService.retrieveAccessToken(AuthService.java:189)
at org.osiam.client.OsiamConnector.retrieveAccessToken(OsiamConnector.java:429)
at osiam.CreateUser.main(CreateUser.java:122)

AccessToken should be serializable to put it in a web session, for example. But to do this we have to agree upon whether the current implementation is sufficient. At this time OSIAM's access tokens are quite simple, maybe too simple for more advanced use cases. Moreover we are still planning to sign tokens, which would at least add a new field (signature). I don't know whether adding a field is considered safe in respect of @Serializable or not.

See also osiam/scim-schema#129.