gluufederation / oxauth Goto Github PK

http://ox.gluu.org/hudson/job/oxAuth/297/testReport/junit/org.xdi.oxauth.ws.rs/AuthorizationCodeFlowHttpTest/authorizationCodeWithNotAllowedScopeFlow/

Currently it's not possible to call internal oxAuth user/password authentication method when there are enabled person authentication methods. oxAuth should accept special acr_value in order to call default authentication method.

I think we should slowly start working towards making our user interface codes a bit more developer friendly, if not user friendly. My main concern is about the fact that the css files and templates are inside the war files; this is causing the IDP's WebUI to revert back to its default state on every update.

What would be the ramifications of moving the WebUI files so that they remain unaffected by the updates?

We can start off with the following files and build up on it as we progress:

/opt/tomcat/webapps/oxauth/stylesheet/theme.css
/opt/tomcat/webapps/oxauth/WEB-INF/incl/layout/template.xhtml
/opt/tomcat/webapps/oxauth/login.xhtml

ACR's cannot share a prefix, because different custom authn methods may have totally different ACRs. It would be best to change the 'Name' field in oxTrust to 'acr' to make it clear.

We need to review person authentication modules and update documentation. The documentation should be simple and allows to install and enable them. This is example: https://github.com/GluuFederation/oxAuth/tree/master/Server/integrations/duo
This module has 2 files INSTALLATION.txt and README.txt
Plus every module should contains sample configuration files if it use them.

Fix the sub claim for id_token and user info endpoint.

The methods

• Integer getAuthLevel();
• String getAuthMode();

Should just be

• String getACR
• String[] getAMRs

According to the spec amr is a list of strings, acr is just one string.

Perhaps the authz interception method should just have a way to retrieve the id_token.

I think we should make a configuration option to force pairwise client registration during client registration. If this is the case, I also think that the openid scope should not return the inum, which is correlatable... but should instead return the pairwise identifier value. This should be editable in the config json (not the file system).

For OpenID Connect Discovery, oxAuth should return the acr_values_supported and am_values_supported according to the available authentication mechanisms. These values should correspond to the LDAP and custom authentication interception scripts that are configured by oxTrust for the domain.

We need to improve gplus custom authn script. A 'workflow' / 'howto' would be great to be included there as well.

Hello,

Running on CentOS 6, 64 bit.
Using the latest install checked out from https://github.com/GluuFederation/install.
OpenDJ ver 2.7.0
Tomcat ver 7.0.54
JRE ver 1.8.0_05 [but also tried openJDK first]

Attached below is the exception I am getting.

Thanks in advance for any assistance,

May 27, 2014 6:13:02 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener
org.jboss.seam.InstantiationException: Could not instantiate Seam component: appInitializer
at org.jboss.seam.Component.newInstance(Component.java:2208)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:343)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:335)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:317)
at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
at org.jboss.seam.init.Initialization.init(Initialization.java:813)
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4973)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at org.gluu.oxtrust.ldap.service.AppInitializer.initiateLDAPAuthConf(AppInitializer.java:449)
at org.gluu.oxtrust.ldap.service.AppInitializer.createApplicationComponents(AppInitializer.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:32)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:79)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:196)
at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:114)
at org.gluu.oxtrust.ldap.service.AppInitializer_$$javassist_seam_5.createApplicationComponents(AppInitializer$$_javassist_seam_5.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2313)
at org.jboss.seam.Component.callCreateMethod(Component.java:2236)
at org.jboss.seam.Component.newInstance(Component.java:2196)
... 19 more

==> /opt/tomcat/logs/catalina.2014-05-27.log <==
May 27, 2014 6:13:02 AM com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra 2.1.7 (SNAPSHOT 20120206) for context '/oxTrust'
May 27, 2014 6:13:04 AM com.sun.faces.spi.InjectionProviderFactory createInstance
INFO: JSF1048: PostConstruct/PreDestroy annotations present. ManagedBeans methods marked with these annotations will have said annotations processed.
May 27, 2014 6:13:06 AM org.richfaces.cache.CacheManager getCacheFactory
INFO: Selected fallback cache factory
May 27, 2014 6:13:06 AM org.richfaces.cache.lru.LRUMapCacheFactory createCache
INFO: Creating LRUMap cache instance using parameters: {org.richfaces.fileUpload.maxRequestSize=2097152, javax.faces.FACELETS_REFRESH_PERIOD=0, org.richfaces.enableControlSkinningClasses=true, javax.faces.DEFAULT_SUFFIX=.xhtml, org.richfaces.fileUpload.createTempFiles=false, org.richfaces.resourceOptimization.enabled=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.enableControlSkinning=true, org.richfaces.skin=emeraldTown}
May 27, 2014 6:13:06 AM org.richfaces.cache.lru.LRUMapCacheFactory createCache
INFO: Creating LRUMap cache instance of 512 items capacity
May 27, 2014 6:13:06 AM org.richfaces.application.InitializationListener onStart
INFO: RichFaces Core Implementation by JBoss by Red Hat, version 4.3.4.Final
May 27, 2014 6:13:06 AM com.sun.faces.config.ConfigureListener$WebConfigResourceMonitor$Monitor
INFO: Monitoring jndi:/localhost/oxTrust/WEB-INF/faces-config.xml for modifications
May 27, 2014 6:13:06 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: Error listenerStart
May 27, 2014 6:13:06 AM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/oxTrust] startup failed due to previous errors

==> /opt/tomcat/logs/localhost.2014-05-27.log <==
May 27, 2014 6:13:06 AM org.apache.catalina.core.StandardContext listenerStop
SEVERE: Exception sending context destroyed event to listener instance of class com.sun.faces.config.ConfigureListener
java.lang.NullPointerException
at javax.faces.component.UIViewRoot.getViewMap(UIViewRoot.java:1542)
at com.sun.faces.config.InitFacesContext.release(InitFacesContext.java:237)
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:352)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:5014)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5659)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:160)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1083)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1880)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

==> /opt/tomcat/logs/catalina.2014-05-27.log <==
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Connection reader for connection 0 to localhost:1389] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Health Check Thread for LDAPConnectionPool(serverSet=FailoverServerSet(serverSets={SingleServerSet(server=localhost:1389)}), maxConnections=3)] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Connection reader for connection 1 to localhost:1389] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Health Check Thread for LDAPConnectionPool(serverSet=FailoverServerSet(serverSets={SingleServerSet(server=localhost:1389)}), maxConnections=3)] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Connection reader for connection 2 to localhost:1389] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/oxTrust] appears to have started a thread named [Health Check Thread for LDAPConnectionPool(serverSet=FailoverServerSet(serverSets={SingleServerSet(server=localhost:1389)}), maxConnections=3)] but has failed to stop it. This is very likely to create a memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/oxTrust] created a ThreadLocal with key of type [com.sun.xml.bind.v2.ClassFactory$1](value [com.sun.xml.bind.v2.ClassFactory$1@5a3119b7]) and a value of type [java.util.WeakHashMap](value [{class org.richfaces.validator.model.ClientSideScripts=java.lang.ref.WeakReference@53c48bef, class org.richfaces.validator.model.Component=java.lang.ref.WeakReference@123c711, class org.richfaces.validator.model.Resource=java.lang.ref.WeakReference@1733b13f}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/oxTrust] created a ThreadLocal with key of type [java.lang.ThreadLocal](value [java.lang.ThreadLocal@451deecf]) and a value of type [com.unboundid.asn1.ASN1Buffer](value [com.unboundid.asn1.ASN1Buffer@32f19e70]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
SEVERE: The web application [/oxTrust] created a ThreadLocal with key of type [com.sun.xml.bind.v2.runtime.Coordinator$1](value [com.sun.xml.bind.v2.runtime.Coordinator$1@2df5dc70]) and a value of type [java.lang.Object[]](value [[Ljava.lang.Object;@27c53ab8]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
May 27, 2014 6:13:06 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deployment of web application archive /opt/tomcat/webapps/oxTrust.war has finished in 13,005 ms
May 27, 2014 6:13:06 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /opt/tomcat/webapps/examples

We need to allow to run oxAuth tests on CE 2.0. In order to do that we need ldif file with testing data needed to run all tests.

Environment:
Ubuntu x64 14.04.1 on VmWare Workstation 11.1.0 build-2496824, Gluu CE 2.3.3-1

Preconditions:

1. LDAP server configured so that it capable of playing ar role of backend directory with a test user account existing in it; the ones provided by MS AD is preferable, but most likely it can be reproduced for any backend directory.
2. Cache Refresh is configured and fully functional so that account mentioned in step one is successfully replicated to Gluu's internal LDAP db and can be used to log in.
3. Fresh installation of Gluu server

Steps to reproduce:

1. Login into oxTrust web UI using default admin account.
2. Move to the "Configuration -> Manage Authentication" page and configure oxAuth so it would use backend LDAP server for authentication; as you will most likely lose ability to log in to web UI after that, either make a dump of oxIDPAuthentication attribute of the inum=@!your_appliance_ID,ou=appliances,o=gluu node, or make a snapshot if you run it in vm possessing such capability.
3. Log out, then try to log in to web UI with some user account stored in backeend directory.

Result: it seems almost like login sequence is interrupted before it can be completed; user is taken to the home page, but regardless of that he can't access any protected functionality and even login page itself (until cookies storage is flushed); "Login failed" message is displayed; it seems it tries to search backend as it would have been its own internal LDAP db; moreover, authentication is actually happens at the very beginning of the log in session - a correct sequence of "LDAP request for subtree -> LDAP request for user object -> LDAP bind request with user's creds" happens and its result is success; but later on a second (and invalid) authentication attempt occurs (the one that results in invalid LDAP request), and it fails this time. See attached screenshot.

Here are log fragment and wireshark capture (limited to LDAP protocol conversations) created during failed login session:
wrapper.log
wireshark's .pcapng

This is Oxd log of "register_client" :
2015-04-09 04:58:48,212 TRACE [org.xdi.oxd.server.Processor] Send back response:
{"status":"ok","data":{"client_id":"@!1111!0008!223B.70C3","client_secret":"79a
db8ec-8d40-40ce-862b-d9bacf74a6e4","registration_access_token":"b7cba86d-e546-4c
00-9cb7-9b98ab7d0c2e","client_secret_expires_at":1428613131000,"registration_cli
ent_uri":"https://seed.gluu.org/oxauth/seam/resource/restv1/oxauth/register?clie
nt_id=@!1111!0008!223B.70C3","client_id_issued_at":1428526731000}}

The extra zero (+000) is added in "client_secret_expires_at" and "client_id_issued_at" fields.
The correct value should be 1428613131, 1428526731

Follow these steps to reproduce:

1. Restart browser
2. Log in using your credentials
3. Logout
4. Click Login again
5. You will log in without entering user/password

Usecase

In Gluu Cluster setup, we deployed replicated LDAP app servers to multiple machines.

1. LDAP server 1 at 10.2.1.1
2. LDAP server 2 at 10.2.1.2

All LDAP servers were included in oxIDPAuthentication entry.

We also deployed oxAuth to 10.2.1.3 This is a gist of oxauth-ldap.properties:

servers=10.2.1.1:1636,10.2.1.2:1636

To test whether oxAuth do the failover, we removed LDAP server 1 from network.

Expected Behaviour

oxAuth will pick available LDAP servers.

Actual Result

oxAuth tried to connect to 10.2.1.1:1636 and didn't pick 10.2.1.2:1636 automatically.

The error messages from logs/catalina.out:

Caused by: LDAPException(resultCode=91 (connect error), errorMessage='An error occurred while attempting to connect to server 10.2.1.1:1636:  java.io.
IOException: An error occurred while attempting to establish a connection to server 10.2.1.1:1636:  java.net.NoRouteToHostException: No route to host'
)
        at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:741)
        at com.unboundid.ldap.sdk.LDAPConnection.connect(LDAPConnection.java:675)
        at com.unboundid.ldap.sdk.LDAPConnection.<init>(LDAPConnection.java:507)
        at com.unboundid.ldap.sdk.SingleServerSet.getConnection(SingleServerSet.java:229)
        at com.unboundid.ldap.sdk.ServerSet.getConnection(ServerSet.java:98)
        at com.unboundid.ldap.sdk.FailoverServerSet.getConnection(FailoverServerSet.java:440)
        at com.unboundid.ldap.sdk.LDAPConnectionPool.createConnection(LDAPConnectionPool.java:616)
        at com.unboundid.ldap.sdk.LDAPConnectionPool.getConnection(LDAPConnectionPool.java:838)
        at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:1855)
        ... 62 more

Any hint about what went wrong with our setup?

If you force the user to enter a custom auth script, it means the jython interpreter must be invoked
This has some overhead.

Update https://github.com/GluuFederation/community-edition-setup template files in order to include next changes:

• Move claims-supported and its mapping from XML config to LDAP
• Enable and disable key regeneration in config
• Other recent changes

In current war there are a lot of new jars. Example: json4s, swagger, etc..
Are they really need in final war?

Use cache to avoid performance decrease.

Register new cache type in conf file oxAuth\Server\src\main\resources\ehcache.xml

Eg: org.xdi.oxauth.service.ClientService
Methonds:
getClientDnByFilters
getClient
getClientByDn
...

http://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg

in example 3, the spec provides a good idea:
"The Issuer creates a Globally Unique Identifier (GUID) for the pair of Sector Identifier and local account ID and stores this value."

Two options;

1. store a json object in the person entry:

dn: inum=<person-inum>,ou=people,o=<org-inum>,o=gluu
oxPersonPairwiseIdentifiers: {'https://example.com/pairwise_client_ids1':'2ade14c0-ffbc-402c-9335-85e5333c939f', ....}

2) create an ou called "ou=pairwiseIdentifiers" under the person and create a sub-entry for each:
dn: id=2ade14c0-ffbc-402c-9335-85e5333c939f,ou=pairwiseIdentifiers,inum=<person-inum>,ou=people,o=<org-inum>,o=gluu
objectclass: top
objectclass: pairwiseIdentifier
oxSectorIdentifierURI:  https://example.com/pairwise_client_ids1

I think I prefer mechanism 2, as it doesn't require substring indexing--just equality and presence indexing for id and oxSectorIdentifierURI

Make sure that this change includes (1) updated schema with comments in the DESC for the objectclass and attributes; (2) test data; (3) test cases; (4) updated indexing ; (5) configuration options in oxAuth to switch between algorithmic pairwise identifiers and persistent pairwise identifiers (and respective documentation so admins know how to configure one or the other.

Update https://github.com/GluuFederation/community-edition-setup template files in order to include authentication session changes.

I think authentication session lifetime should be bigger than 1 minute and less that 3 minutes.
What about 90 seconds - 2 minutes? I think it's enough for one authentication step. This time also allow to make few authentication attempts... or recieve DUO push notification..

Perhaps we can define in oxAuth a way for the admin to set what gets returned as amr.
AMR is a list of strings, returned by the OP, to provide more information about the authentication that happened. No one knows what the company may want to return for amr--values are out of scope of OpenID Connect. For example, one could imagine amr's returned such as ['10', 'https://example.com/acr/duo', 'silver']

The best way to handle this is to enable the company to set the amr values in the interception script. We should add a method 'def setAmrValues(self, amrValuesList): where amrValues is a python list.

There are few TODO for ACR.

1. There is acr claim in IdToken.
   I used basic method for authentication
   This is result list of claim of IdToken
   {"iss":"https://seed22.gluu.org","aud":"@!D79B.BDA4.A74F.453F!0008!EC89.22E8","exp":1432733067,"iat":1432729467,"nonce":"nonce","auth_time":1432729466,"c_hash":"HzIUSO3TlYfTBj0lhBO8PA","oxValidationURI":"https://seed22.gluu.org/oxauth/opiframe","oxOpenIDConnectVersion":"openidconnect-1.0","user_name":"admin","inum":"@!D79B.BDA4.A74F.453F!0001!9573.5466!0000!A8F2.DE1E.D7FB","name":"Default Admin User","family_name":"User","given_name":"Admin"}
   it should contains acr
2. oxTrust was not updated to use acr instead of auth_mode
3. Also in sections 3.1.3.7, 5.5. 5.5.1.1, 16.20. there are information that it's possible to request acr claim
   I'm not sure that these endpoints can return acr claim

This sample code allows to create HttpClient which works through proxy server

    public static HttpClient createProxyHttpClient(String proxyHost, int proxyPort, String proxyUser, String proxyPassword) throws KeyManagementException, UnrecoverableKeyException, NoSuchAlgorithmException, KeyStoreException {
        SchemeRegistry registry = new SchemeRegistry();
        registry.register(new Scheme("http", 80, PlainSocketFactory.getSocketFactory()));
        registry.register(new Scheme("https", 443, SSLSocketFactory.getSystemSocketFactory()));

        ClientConnectionManager clientConnectionManager = new PoolingClientConnectionManager(registry);
        DefaultHttpClient httpClient = new DefaultHttpClient(clientConnectionManager);
        httpClient.getParams().setParameter(org.apache.http.conn.params.ConnRoutePNames.DEFAULT_PROXY,
                new HttpHost(proxyHost, proxyPort, "http"));

        // The proxy has optional authentication. The authentication information was set using the following code:
        if (StringHelper.isNotEmpty(proxyUser) && StringHelper.isNotEmpty(proxyPassword)) {
            httpClient.getCredentialsProvider().setCredentials(new AuthScope(proxyHost, proxyPort),
                    new UsernamePasswordCredentials(proxyUser, proxyPassword));
        }

        return httpClient;
    }

Also all oxAuth clients allows to set specified executor. Hence in order to use proxy client we need to do next for example:

        // Build client executor to use proxy
        HttpClient httpClient = createProxyHttpClient(proxyHost, proxyPort, proxyUser, proxyPassword);
        ClientExecutor clientExecutor = createClientExecutor(httpClient);
        authorizeClient.setExecutor(clientExecutor);

I think we can do than automatically.

Base client can detect if there are system properties with proxy configuration and use it if needed : -Dhttp.proxyHost=proxy.server.com -Dhttp.proxyPort=80, etc...

Also our method to install BCProvider is not convenient and led to errors if user decides to change java. I think we need use programmaticaly way to install BCProvider.
This is example from EJBCA client samples:
CryptoProviderTools.installBCProvider();

This is CryptoProvider code for reference: http://fisheye.primekey.se/browse/CESeCore/trunk/cesecore/src/main/java/org/cesecore/util/CryptoProviderTools.java?r1=1554&r2=1331&u=3

Instead of calling method to install BCProvider we can implement logic to call this method automatically on request to server to cover generic scenarios. But we also should have ability to call it from user code.

OAuth requires the client id to be encoded "using the 'application/x-www-form-urlencoded' encoding algorithm" (http://tools.ietf.org/html/rfc6749#section-2.3.1). This is obviously not respected when a OIDC-Client accesses the UserInfo Endpoint in the Authorization Code Flow, the missing decoding results in an "invalid_client" error response. You can reproduce this with the example client of connect2id (https://bitbucket.org/connect2id/openid-connect-dev-client), it's also discussed here: https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/issue/129/clientsecretbasic-incorrectly-url-encodes

When the id_token is returned from the user_info endpoint, the Gluu Server should expose one last interception script that enables you to massage the values for the attributes originating in LDAP. This dynamic attribute generation should only occur if the oxAuthCustomScope type attribute == "dynamic"

The only method required is "update" similar to the dynamic attribute synchronization script. The current LDAP values should also be sent into the User object, so they are available in the script.

There should be some error message(**) if any user use wrong credential.
I am talking about beta3 and "gluu-server-beta3-1.7-0.el6.x86_64.rpm"

(**) "Please use correct username and password"

CR mechanism is not tested to pull and store binary attributes.

Some customer require ObjectGUID ( a binary attribute in Active Directory ) to pull into their Gluu Server as this binary attribute can be released to Microsoft specific services ( i.e. Office365 ).

I tried to create a custom attribute named 'ObjectGUID' ( format of attribute: photo ) and pulled AD's ObjectGUID. Seems like values are changing when it is coming into Gluu-LDAP.

As for example: ObjectGUID in backend AD might be: 1+4wBZy0kqqGzsgU8tUvXw==
But when it is coming into Gluu-LDAP, it turns to 77+977+9MAXvv37vv37vv71B77+797+9OBTvv73vv70vXw==

In CE we get next error in installation log:
6:42:01 04/02/15 Runnning: /bin/su tomcat -c /usr/java/latest/bin/java -cp /home/tomcat/lib/bcprov-jdk16-1.46.jar:/home/tomcat/lib/commons-lang-2.6.jar:/home/tomcat/lib/log4j-1.2.14.jar:/home/tomcat/lib/commons-codec-1.5.jar:/home/tomcat/lib/jettison-1.3.jar:/home/tomcat/lib/oxauth-model.jar:/home/tomcat/lib/oxauth.jar org.xdi.oxauth.util.KeyGenerator
16:42:05 04/02/15 log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /logs/oxauth_persistence_ldap_statistics.log (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:221)
at java.io.FileOutputStream.(FileOutputStream.java:142)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:289)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:163)
at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:215)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:256)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:220)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:163)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:425)
at org.apache.log4j.xml.DOMConfigurator.parseCategory(DOMConfigurator.java:345)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:827)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.apache.log4j.LogManager.(LogManager.java:122)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
at org.xdi.oxauth.model.util.JwtUtil.(JwtUtil.java:84)
at org.xdi.oxauth.model.crypto.signature.RSAPrivateKey.toJSONObject(RSAPrivateKey.java:57)
at org.xdi.oxauth.model.crypto.Key.toJSONObject(Key.java:112)
at org.xdi.oxauth.util.KeyGenerator.generateRS256Keys(KeyGenerator.java:66)
at org.xdi.oxauth.util.KeyGenerator.main(KeyGenerator.java:31)
log4j:ERROR Either File or DatePattern options are not set for appender [OX_PERSISTENCE_LDAP_STATISTICS_FILE].
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: /logs/oxauth.log (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:221)
at java.io.FileOutputStream.(FileOutputStream.java:142)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:289)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:163)
at org.apache.log4j.DailyRollingFileAppender.activateOptions(DailyRollingFileAppender.java:215)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:256)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:220)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:163)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:425)
at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:394)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:829)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.apache.log4j.LogManager.(LogManager.java:122)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
at org.xdi.oxauth.model.util.JwtUtil.(JwtUtil.java:84)
at org.xdi.oxauth.model.crypto.signature.RSAPrivateKey.toJSONObject(RSAPrivateKey.java:57)
at org.xdi.oxauth.model.crypto.Key.toJSONObject(Key.java:112)
at org.xdi.oxauth.util.KeyGenerator.generateRS256Keys(KeyGenerator.java:66)
at org.xdi.oxauth.util.KeyGenerator.main(KeyGenerator.java:31)
log4j:ERROR Either File or DatePattern options are not set for appender [FILE].

oxAuth should has reload configuration process which should check if there is marker file in conf folder like oxauth.config.reload

I was reading this article: http://gluu.co/connect-deep-dive and this part jumped out at me:

NOTE: The AS may or may not issue a refresh token to a particular client. Issuing such a token is ultimately a trust decision. If you have doubts about a client’s ability to keep these privileged tokens safe, don’t issue it one!

The configuration for refresh tokens should be stored in the client ldap entry and exposed as client configuration in oxtrust.

Corresponding feature requrest in oxTrust: GluuFederation/oxTrust#523

It's possible to pass requested acr_values to oxAuth. But oxAuth selects only one method. We need to show intermediary form to allow user select one of the methods specified in acr_values

There is missing part in oxAuth which gather statistic. For example oxAuth should count number of successful/failed authentications, active sessions, etc..

We need to implement serverStatistic service. It should have methods which allows to gather statistic for specified counter. Example:
serverStatistic.increaseCounter(counter_type_name, value);
serverStatistic.setCounter(counter_type_name, value);
...

In order to avoid performance decrease this service should persist statistic in LDAP asynchronously and withing hard-coded specified interval, example: 5 minutes.

The statistic model should be multi-level:

1. serverStatistic should store data in:
   ou=statistic,o=[org_inum],o=gluu

2. Next level should be for specified server:
   ou=DNS_server_name,o=[org_inum],o=gluu

3. This is sample entry of next level (year+month+date):
   ou=YYYY-MM-DD,ou=DNS_server_name,o=[org_inum],o=gluu

4. uniqueIdentifier=XYZ,ou=YYYY-MM+DD,ou=DNS_server_name,o=[org_inum],o=gluu
   oxEventDate: 20150707165206.955Z
   oxEventApplicationType: oxAuth
   oxEventType: user_authentication_success
   oxEventCounterType: sum/average/etc..
   oxEventData: {counter_data in JSON format}

http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

CE 2.3.2 after changing oxauth-config.xml reloads configuration. Hence we can change next properties on the fly:
<auth-filters-enabled>false</auth-filters-enabled> <client-auth-filters-enabled>false</client-auth-filters-enabled>
to
<auth-filters-enabled>true</auth-filters-enabled> <client-auth-filters-enabled>true</client-auth-filters-enabled>
As result oxAuth reloads configuration but these filters still not work until tomcat restart.

It's bug.

http://ox.gluu.org/hudson/job/oxAuth-Benchmark/

The authn interception scripts are here
https://github.com/GluuFederation/oxAuth/tree/master/Server/integrations

I think it would be better to create a folder substructure for sample scripts. For example:

oxauth/sample/interception/
oxauth/sample/interception/authentication
oxauth/sample/interception/authorization
etc.

oxAuth client should provides method to load public certificate or allow specify path to certificate in file system. It’s generic solution for all client API libraries.

In current version acr_values paramter is JSON array. We need to update application to allow pass it as space-separated string.

During oxAuth client tests execution on Seed21 there is one test failure:
http://ox.gluu.org/hudson/job/oxAuth_seed21/9/testReport/org.xdi.oxauth.ws.rs/OpenIDRequestObjectHttpTest/requestFileMethodFail2/

We temporary disable this validation: e08c69f

We need to fix test or testing data set.

We need to remove inboundSaml if saml module covers it functionality

The three EC JWKs at https://seed.gluu.org/oxauth/seam/resource/restv1/oxauth/jwks [1] [2] have "alg":"EC", which isn't a valid JSON Web Signature or Encryption Algorithm as indicated that the alg value should be in JWK [3] [4].

[1] https://seed.gluu.org/oxauth/seam/resource/restv1/oxauth/jwks

{"keys": [
    {
        "kty": "RSA",
        "kid": "1",
        "use": "sig",
        "alg": "RS256",
        "n": "AJYQhwMG7-PCPzmp-E8_Jz8zGVuIA0upMUrqOLa9lpcduLXlpgv_g525DU8vJ34GqNgYcsjNw2dvV03cWSU8VguWSC5ijHfhzf3cSbEJTcBOfCpbir8hRgAOkU4gqSf8rXTugyJ6jw4wiMEnLlk8j18chGQvn-bqKDw9aEqg_ssxz3f0yO_p4bl5_9n5FGQHGyZYv6B_PsAHZkm_DNDu7Wa_vfv8vnq3u_38uf4WC6S5cMR15B74Ja0ylR498h23E2riz9o7X2rLsL26JLUWSfjDw-twYqF4jt6oCGDIIv4zCYdpim-2L5qKMkASPAbWs_KfXIIhJuLohrpzOaqZh_k",
        "e": "AQAB",
        "x5c": ["MIIDMDCCAhgCgYBDSFLKDmTPKXlpVPR8EuhbSUGCgd2okr\/tL7sW9nlr6oKpNovrEFUL0YkqT59dNG7zldXJWY92VQDJSmpeRX6TX74efV1prpF4Y9sW5y0iu9njcAxE2zDBCM6rGWNf+WWajOajuYkbqEfOOl1PikQkFCliIUdDYSvId6Sco05tsjANBgkqhkiG9w0BAQsFADAeMRwwGgYDVQQDExNUZXN0IENBIENlcnRpZmljYXRlMB4XDTEzMDIxMTIxMjQxMloXDTE0MDIxMTIxMjQxMlowHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJYQhwMG7+PCPzmp+E8\/Jz8zGVuIA0upMUrqOLa9lpcduLXlpgv\/g525DU8vJ34GqNgYcsjNw2dvV03cWSU8VguWSC5ijHfhzf3cSbEJTcBOfCpbir8hRgAOkU4gqSf8rXTugyJ6jw4wiMEnLlk8j18chGQvn+bqKDw9aEqg\/ssxz3f0yO\/p4bl5\/9n5FGQHGyZYv6B\/PsAHZkm\/DNDu7Wa\/vfv8vnq3u\/38uf4WC6S5cMR15B74Ja0ylR498h23E2riz9o7X2rLsL26JLUWSfjDw+twYqF4jt6oCGDIIv4zCYdpim+2L5qKMkASPAbWs\/KfXIIhJuLohrpzOaqZh\/kCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAA1c5yds2m89XnhEr+WFE8APdkveJDxa+p7R5TSR924+nq4v11UPzSqkpn+Nk\/QYM6uUBH1Z0axBgrFy\/auunXbtDfm\/HzQkTx+Dlq4DgcTzUKUC\/3ObfVQCEFCaKfbtg+PTM7QytJgeoGPbjWneIvgis3zvmCULknGt\/7CYh2URAaBkWitLBuYa0yCnPSfajNpnMrOEPBElsU0lC+ka4N\/C\/v5nvkfnneMDnr8UMV2OkRv+BDyoUg5HWgtWNV7AE0I7I89aVmLxWGp0tWwnZxbfbfGChGEhHHgx0eri9L4+Hd9l5ZP1csuojHoHHcMSmaT2\/4edG4Eyxm6C2GPrCGg=="]
    },
    {
        "kty": "RSA",
        "kid": "2",
        "use": "sig",
        "alg": "RS384",
        "n": "ALs6oVo2LGaBb39Z8loTmhiZhZPq0wbfTpvhFjFoEXJRTLlucPYftbV3g_aTmUiL_Pz919nWCj-X2WOtE3g7du823qJqX8ieas_c7ehZcG8D-pxxUipRqBDX76Bw6jZ00QtEcc89MU4GJaROHcm0L8iQMkSZgIFN8u5_ZvtQzWyynXTmHve0nNMoVhTn1nrxK_dGotCDkzJZ3ph7Rjq5smxjoPGrzzeesCo9c_3edrD4jiFkDUlEOabvqfhTeX1K_X3HO-LHBBI2QxvP7U1MarxyP8TMsIQjjR1ggGNkdv4gtTK5AixjHlQYswQragzBWQ5dTrUNl366NNpYTD3-o3M",
        "e": "AQAB",
        "x5c": ["MIIDMDCCAhgCgYBmLjh1H5nHW466kS5EPsNmi+92mYsiRZ4Al+GOLr\/067Dpy\/qwiSHVcIsY0pPCORukIvwxf2CUHeKRg7HDD87jddENjlcEpUDNT9EjxixymSbrQEerPliD69MCTqGp6KyfRrf44cuEQFDdSQbYW+b25Ivms33sLim+\/5uENE7MbjANBgkqhkiG9w0BAQwFADAeMRwwGgYDVQQDExNUZXN0IENBIENlcnRpZmljYXRlMB4XDTEzMDIxMTIxMjQxM1oXDTE0MDIxMTIxMjQxM1owHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALs6oVo2LGaBb39Z8loTmhiZhZPq0wbfTpvhFjFoEXJRTLlucPYftbV3g\/aTmUiL\/Pz919nWCj+X2WOtE3g7du823qJqX8ieas\/c7ehZcG8D+pxxUipRqBDX76Bw6jZ00QtEcc89MU4GJaROHcm0L8iQMkSZgIFN8u5\/ZvtQzWyynXTmHve0nNMoVhTn1nrxK\/dGotCDkzJZ3ph7Rjq5smxjoPGrzzeesCo9c\/3edrD4jiFkDUlEOabvqfhTeX1K\/X3HO+LHBBI2QxvP7U1MarxyP8TMsIQjjR1ggGNkdv4gtTK5AixjHlQYswQragzBWQ5dTrUNl366NNpYTD3+o3MCAwEAATANBgkqhkiG9w0BAQwFAAOCAQEAS7rNA06jrBPCLMuUq38jlHolnPHQxS1Qg0aUUCNy955AMnoh4tF60ejIxIwiZIXZdWBR0cIDxV+8Cy3WYj4a8FDQnntVR0dREfGQyICf0v5reEenSj2u2DUHgCpwFbpmrh9UTjg0swU9G06LV+q\/arDq+ejK9Wty8fWBw7RSpx3s5nq7xuA+TY4wqGTtIdPAI1q4oWOHn0x65FV6Mwv3Lis8gSXIvBhzjkAIh6PXK7YMic43sR6MGOKCJ3iO5bqW2kSJ0KQXOv6nxUwrs9k2dgrTxdUwNycZEYiQEiXK\/sPHIhqEmRZK6H00dLz\/99K4ZLm17YeF+7g4Sk0ZkMarpw=="]
    },
    {
        "kty": "RSA",
        "kid": "3",
        "use": "sig",
        "alg": "RS512",
        "n": "AK3SFO9Q0jJP1-n2ys7yyP70r149_EQ1z0EfgIg2qpAMXcuyDIWu-dqD05fkicN2izHAf463LydeRUXWAc058F-mYw8y69qcZyDxnqYu_IlmK77tDgE-oilPVF_JW3WMXAl3MHvhAQwc-2q2lLbs3qa6BqpZgXofiJdURaRS990qO1fqYm1ihT8hmq8WQmXbDS_0-L4sP3O8cK9FXWhWqtfC1yo0Ziv8OSQ3h8dYRFAupqESRpe3EzV5DICdHAdBBrSkLyfPTLIzavfCkhI4zB6VrxLF4l1yTo7ucfnobIUaiNEvwVwkytLrNM4HPk4dO8H0woEomqj4QzIPkUGLxLc",
        "e": "AQAB",
        "x5c": ["MIIDMDCCAhgCgYA6qJ8lNNfbB0VhX2UZLXLizoC1BCPEc2W25\/hJKay\/GXVMIA+42AvUqWSonkwDALudfWbPVR3vOqB8iq4O75aaGiEAw6roiOHHRVTCZm1PCH+TlGh+jATybe83cBtCGTmvt81Or4q0NK\/sJ3hi3e\/ds4IPn3eWScd1lhVUzIj2uDANBgkqhkiG9w0BAQ0FADAeMRwwGgYDVQQDExNUZXN0IENBIENlcnRpZmljYXRlMB4XDTEzMDIxMTIxMjQxM1oXDTE0MDIxMTIxMjQxM1owHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK3SFO9Q0jJP1+n2ys7yyP70r149\/EQ1z0EfgIg2qpAMXcuyDIWu+dqD05fkicN2izHAf463LydeRUXWAc058F+mYw8y69qcZyDxnqYu\/IlmK77tDgE+oilPVF\/JW3WMXAl3MHvhAQwc+2q2lLbs3qa6BqpZgXofiJdURaRS990qO1fqYm1ihT8hmq8WQmXbDS\/0+L4sP3O8cK9FXWhWqtfC1yo0Ziv8OSQ3h8dYRFAupqESRpe3EzV5DICdHAdBBrSkLyfPTLIzavfCkhI4zB6VrxLF4l1yTo7ucfnobIUaiNEvwVwkytLrNM4HPk4dO8H0woEomqj4QzIPkUGLxLcCAwEAATANBgkqhkiG9w0BAQ0FAAOCAQEASyqKmhz7o5VjB5gKSBaLw9yqNo8zruYizkLKhUxzAdna6qz73ONAdXtrdok79Qpio2nlvyPgspF9rYKgwxguvHpTOkdCZ3LNPF4QLsn3I0vs3gr8+oXhXbA58kqsBSAyt54HDTa7Zh8c\/G1u5W\/0+lsgCwtMSzeISnNrqY3a3K97Uy6OoxDqWk8t4W1OgtYhi6wiq7BGQ9xg7QlwMrVNc165ixgaW46\/tpafONG7+WFaWnzROPHrh6rSv4diz8bd7MqDDVLB2q\/QolzWTtxHSgkFu1t5dNEQznJI5Ay\/txPKgRNiv3EhD8fv9EKsip1epKtsP5Il6mLktPBjZMHjMg=="]
    },
    {
        "kty": "EC",
        "kid": "4",
        "use": "sig",
        "alg": "EC",
        "crv": "P-256",
        "x": "eZXWiRe0I3TvHPXiGnvO944gjF1o4UmitH2CVwYIrPg",
        "y": "AKFNss7S35tOsp5iY7-YuLGs2cLrTKFk80JvgVzMPHQ3",
        "x5c": ["MIIBpDCCAUoCgYBCs6x21IvwVHFgJxiRegyHdSiEHFur9Wj2qM5oNkv6sFbbC75L849qCgMEzdtqIhCiCnFg6PaQdswHkcclXix+y0sycyIM6l429faY3jz5eQs5SYwXYkENStzTZBsWK6u7bPiV3HvjnIv+r1af8nvO5F0tiH0TC+auDj9FgRmYljAKBggqhkjOPQQDAjAeMRwwGgYDVQQDExNUZXN0IENBIENlcnRpZmljYXRlMB4XDTEzMDIxMTIxMjQxMVoXDTE0MDIxMTIxMjQxMVowHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABHmV1okXtCN07xz14hp7zveOIIxdaOFJorR9glcGCKz4oU2yztLfm06ynmJjv5i4sazZwutMoWTzQm+BXMw8dDcwCgYIKoZIzj0EAwIDSAAwRQIhAI4aRAoTVm3was6UimA1lFL2RId+t\/fExaviosXNKg\/IAiBpZB4XXcnQISwauSJ1hXNnSEcONXdqvO5gDHu+X7QHLg=="]
    },
    {
        "kty": "EC",
        "kid": "5",
        "use": "sig",
        "alg": "EC",
        "crv": "P-384",
        "x": "XGp9ovRmtaBjlZKGI1XDBUB6F3d4Xov4JFKUCaeVjMD0_GAp20IB_wZz6howe3yi",
        "y": "Vhy6zh3KOkDqSA5WP6BtDyS9CZR7RoCCWfwymBB3HIBIR_yl32hnSYXtlwEr2EoK",
        "x5c": ["MIIB4zCCAWgCgYEA9v7jYfmKYNePYWQt6M8BQsvb4swqpVEYulCJq8bOKuhz5\/VgM8J8lGaClDRhY6msrtW16kRbZvnMvgKNBJ52TXGKtEFylMzDQ4k\/HYGb1w7FwlXVyv3TScFNm9JnfsMe7ecOcanRFn+hYjiZdEcTB85wLvpKRDlkpuIf0khB8iMwCgYIKoZIzj0EAwIwHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTAeFw0xMzAyMTEyMTI0MTFaFw0xNDAyMTEyMTI0MTFaMB4xHDAaBgNVBAMTE1Rlc3QgQ0EgQ2VydGlmaWNhdGUwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAARcan2i9Ga1oGOVkoYjVcMFQHoXd3hei\/gkUpQJp5WMwPT8YCnbQgH\/BnPqGjB7fKJWHLrOHco6QOpIDlY\/oG0PJL0JlHtGgIJZ\/DKYEHccgEhH\/KXfaGdJhe2XASvYSgowCgYIKoZIzj0EAwIDaQAwZgIxAOV6rC\/muVarcSXaP9Z7Pn7aI3o5fixoVx6E\/xYTOg+H10FMsluIdahjt90fNJYiYAIxAO+IHenKHe2xr8RpphzqWnAexswcEI6A3drp1f24Z8XtTJHNIHAVP6wr88oz5+eFoQ=="]
    },
    {
        "kty": "EC",
        "kid": "6",
        "use": "sig",
        "alg": "EC",
        "crv": "P-521",
        "x": "KrVaPTvvYmUUSf_1UpwJt_Lg9UT-8OHD_AUd-d7-Q8Rfs4t-lTJ5KEyjbfMzTHsvNulWftuaMH6Ap3l5vbDb2nQ",
        "y": "AIxSEGvlKlWZiN_Rc3VjBs5oVB5l-JfCZHm2LyZpOxAzWrpjHlK121H2ZngM8Ra8ggKa64hEMDE1fMV__C_EZv9m",
        "x5c": ["MIICLDCCAY0CgYAcLY90WqvtOS1H1zyF0jrrHT549yccB4rk61J96JlOnRTbuTq7wWWgOm6csS+19GMRIIDk5njc6M50WUeCcFEURy9wmZKAW3\/PgOgnPydjnvBIIofOfZOVeaLjji64h7Ju\/Ur8Ki28sN5xeyz5iGhqst1CJ0RVBAbpT4IN2szemTAKBggqhkjOPQQDAjAeMRwwGgYDVQQDExNUZXN0IENBIENlcnRpZmljYXRlMB4XDTEzMDIxMTIxMjQxMVoXDTE0MDIxMTIxMjQxMVowHjEcMBoGA1UEAxMTVGVzdCBDQSBDZXJ0aWZpY2F0ZTCBmzAQBgcqhkjOPQIBBgUrgQQAIwOBhgAEACq1Wj0772JlFEn\/9VKcCbfy4PVE\/vDhw\/wFHfne\/kPEX7OLfpUyeShMo23zM0x7LzbpVn7bmjB+gKd5eb2w29p0AIxSEGvlKlWZiN\/Rc3VjBs5oVB5l+JfCZHm2LyZpOxAzWrpjHlK121H2ZngM8Ra8ggKa64hEMDE1fMV\/\/C\/EZv9mMAoGCCqGSM49BAMCA4GMADCBiAJCAb+BYADga2su9Sejzgbfz4lrSPt1l7PWeyDXtTGqa8yvIf4f3Hudp272WeXxeBpL\/7EFtho8CvG8zhvrp7bC+E84AkIBv3V6seORxzsO5hv1mtAKIPdFmePIrKrGFqa7ESR56DZxVYeJ5GHi1gU4LJdGcUYDpz0GDqznxAmvA3AimrwAWUk="]
    }
]}

[2] http://osis.idcommons.net/wiki/OC5:OpenID_Connect_Interop_5

[3] https://tools.ietf.org/html/draft-ietf-jose-json-web-key-39#section-4.4

[4] https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-3.1

UMA : update oxAuth according to new specification

[5/11/15, 3:30:50 PM] Javier Rojas: Hello Yuriy
[5/11/15, 3:31:05 PM] Javier Rojas: I found a strange behaviour in oxAuth
[5/11/15, 3:31:31 PM] Javier Rojas: seems like a cache issue or maybe something related…
[5/11/15, 3:31:46 PM] Javier Rojas: Please try this steps to reproduce:
[5/11/15, 3:32:50 PM] Javier Rojas: 1. In Chrome browser or another open a New Incognito Window (just to ensure you have no initial cookies)
[5/11/15, 3:33:14 PM] Javier Rojas: 2. Go to: https://seed21.gluu.org/oxauth/seam/resource/restv1/oxauth/authorize?scope=openid&response_type=code&redirect_uri=https%3A%2F%2Fop.certification.openid.net%3A60076%2Fauthz_cb&state=VRm0pYs390MyTyjb&client_id=%40%21BD82.DCC9.37DE.103B%210001%21E167.1531%210008%21EE56.93F7&acr_values=1+2
[5/11/15, 3:33:37 PM] Javier Rojas: 3. Use credentials: javier / secret
[5/11/15, 3:34:50 PM] Javier Rojas: 4. Accept the authorisation form, you will be redirected to the redirect uri in op.certification.openid.net/…
[5/11/15, 3:35:02 PM] Javier Rojas: 5. In the same window Go to: https://seed21.gluu.org
[5/11/15, 3:35:52 PM] Javier Rojas: 6. See what happens… the old redirect uri seems to be cached?! o_O
[5/11/15, 3:36:06 PM] Javier Rojas: What do you think?
[5/11/15, 3:37:07 PM] Yuriy Movchan: I get error page.
URL: https://op.certification.openid.net:60076/authz_cb?session_id=200508dd-cbda-4bc8-a21d-b946bce7b885&scope=openid&state=VRm0pYs390MyTyjb&code=b6f47ce3-e985-429f-9893-7e192cef1b99
Page:
OpenID Certification OP Test
Sorry ! An unforseen error occured
S
To go back to the list of tests click this link.
To go back click this link.
[5/11/15, 3:37:32 PM] Javier Rojas: yes, please ignore it
[5/11/15, 3:37:49 PM] Javier Rojas: the problem is with subsequent requests
[5/11/15, 3:38:01 PM] Javier Rojas: the request seems to be cached
[5/11/15, 3:39:40 PM] Yuriy Movchan: I think it's bug.
[5/11/15, 3:41:22 PM] Yuriy Movchan: We store initial requests parameters in LDAP (for 1 minutes with status unathenticated). After user authentication we change status that user authentication
[5/11/15, 3:41:52 PM] Yuriy Movchan: I think Yuriy Z should modify code to override them if it;s new authorization requests
[5/11/15, 3:42:13 PM] Yuriy Movchan: Now oxAuth uses session_id to retreview params from LDAP
[5/11/15, 3:42:40 PM] Yuriy Movchan: He should add check to cover your scenario
[5/11/15, 3:42:59 PM] Yuriy Movchan: We need to open issue in gitlab with you description and my comments if needed
[5/11/15, 3:43:04 PM] Yuriy Movchan: And assign it to Yuriy Z

We are using JSF to render pages in oxAuth. According JSF documentation workflow is not very simple: https://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html

Restore View Phase
When a request for a JavaServer Faces page is made, such as when a link or a button is clicked, the JavaServer Faces implementation begins the restore view phase.
During this phase, the JavaServer Faces implementation builds the view of the page, wires event handlers and validators to components in the view, and saves the view in the FacesContext instance, which contains all the information needed to process a single request. All the application’s component tags, event handlers, converters, and validators have access to the FacesContext instance.
...
If the request for the page is a postback, a view corresponding to this page already exists. During this phase, the JavaServer Faces implementation restores the view by using the state information saved on the client or the server.

Hence on postback server should have stored view in FacesContext in order to process request. But we are trying to not depend on framework persistent data on server!!!

How to resolve issue:
I think we need to get rid of JSF in oxAuth. I think so because we are using it only to render few very simple pages. Also it led to issue with cluster in our case. Also as far as I remember JSF requires memory to holds HTML components tree, states, etc..
The simple replacement is jsp + few new rest endpoints to process login/authorization form postback. Or use bootstarap instead of simple jsp if we need to make login/autorization form more attractive.
We need to retest everything after update. Also we need to retest 2F authentication, our sessions..