AppSuite:OAuth 2 0 Provider Operator Guide - Revision history

Khgras at 09:16, 15 May 2019

2019-05-15T09:16:20Z

← Older revision		Revision as of 09:16, 15 May 2019
Line 3:		Line 3:
	= Open-Xchange OAuth 2.0 Provider Operator Guide =		= Open-Xchange OAuth 2.0 Provider Operator Guide =

	The content on this page has moved to https://documentation.open-xchange.com/~~latest~~/middleware/~~components~~/~~oauth_provider~~.html.		The content on this page has moved to https://documentation.open-xchange.com/7.10.2/middleware/login_and_sessions/oauth_2.0_provider.html.

	Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.		Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.

Khgras at 10:31, 22 May 2017

2017-05-22T10:31:53Z

← Older revision		Revision as of 10:31, 22 May 2017
Line 3:		Line 3:
	= Open-Xchange OAuth 2.0 Provider Operator Guide =		= Open-Xchange OAuth 2.0 Provider Operator Guide =

	The content on this page has moved to https://documentation.open-xchange.com/~~7.8.2~~/middleware/components/oauth_provider.html.		The content on this page has moved to https://documentation.open-xchange.com/latest/middleware/components/oauth_provider.html.

	Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.		Note: Open-Xchange is in the process of migrating all its technical documentation to a new and improved documentation system (documentation.open-xchange.com). Please note as the migration takes place more information will be available on the new system and less on this system. Thank you for your understanding during this period of transition.

Khgras at 09:09, 12 July 2016

2016-07-12T09:09:07Z

Show changes

Steffen.templin at 12:45, 6 February 2016

2016-02-06T12:45:48Z

@@ Line 3: / Line 3: @@
 = Open-Xchange OAuth 2.0 Provider Operator Guide =
-With OX App Suite v7.8.0 a service provider can decide to publish a certain subset of the OX HTTP API via OAuth 2.0. See the [[AppSuite:OAuth_2_0_Client_Developer_Guide|developer guide]] for an overview of the available APIs. The feature as a whole is contained in separate optional packages and requires some configuration. Supported client applications must be of type <code>confidential</code> according to the <code>web application</code> profile defined in [http://tools.ietf.org/html/rfc6749 RFC 6749]. Every application must be registered at the OX backend. The registration process is up to you, while the backend provides SOAP and RMI interfaces to persist those registrations and generates the client-specific credentials that are needed to gain access for granting users.
+With OX App Suite v7.8.0 a service provider can decide to publish a certain subset of the OX HTTP API via OAuth 2.0. See the [[AppSuite:OAuth_2_0_Client_Developer_Guide|developer guide]] for an overview of the available APIs. The feature as a whole is contained in separate optional packages and requires some configuration. Supported client applications must be of type <code>confidential</code> according to the <code>web application</code> profile defined in [http://tools.ietf.org/html/rfc6749 RFC 6749]. The OX middleware will act as <code>resource server</code> and by default also as <code>authorization server</code>.
 == Installation and Configuration ==
@@ Line 11: / Line 13: @@
 <pre>$ apt-get install open-xchange-oauth-provider open-xchange-admin-oauth-provider</pre>
-Configuration takes place in <code>/opt/open-xchange/etc/oauth-provider.properties</code>. There you must enable the feature and provide an encryption key. The encryption key is used to encrypt the credentials of client applications within the database. You MUST set a value here and this value must be the same on all groupware and provisioning nodes. Example:
+Configuration takes place in <code>/opt/open-xchange/etc/oauth-provider.properties</code>. The feature is disabled by default and must be activated manually.
 <pre># Set to 'true' to basically enable the OAuth 2.0 provider. This setting can then be overridden
@@ Line 19: / Line 27: @@
 # Default: false
 com.openexchange.oauth.provider.enabled=true
 # Specify how authorization codes shall be stored, to enable OAuth in multi-node environments.
@@ Line 664: / Line 685: @@
     &lt;/soap:Body&gt;
 &lt;/soap:Envelope&gt;</pre>

Khgras: /* SOAP Provisioning */

2015-08-04T13:26:41Z

SOAP Provisioning

Show changes

Khgras: /* RMI Provisioning */

2015-08-04T13:24:06Z

RMI Provisioning

← Older revision		Revision as of 13:24, 4 August 2015
Line 88:		Line 88:

	</table>		</table>
	=== RMI Provisioning ===		== RMI Provisioning ==

	To use RMI as provisioning mechanism you need to link your code against the correct API classes. You'll find the according JAR files on your provisioning node. Navigate to <code>/opt/open-xchange/libs</code> and fetch <code>com.openexchange.admin.rmi.jar</code> and <code>com.openexchange.oauth.provider.rmi.jar</code>. Note that both files are symlinks. Besides the JARs you'll find the according JavaDoc in <code>/usr/share/doc/open-xchange-admin/javadoc</code> and <code>/usr/share/doc/open-xchange-oauth-provider/javadoc</code>. After adding both JARs to your classpath you can start development. The remote interface is <code>com.openexchange.oauth.provider.rmi.RemoteClientManagement</code>. Below you find an example of all operations that manipulate client data. Of course there are also methods to list and get all or certain registered clients.		To use RMI as provisioning mechanism you need to link your code against the correct API classes. You'll find the according JAR files on your provisioning node. Navigate to <code>/opt/open-xchange/libs</code> and fetch <code>com.openexchange.admin.rmi.jar</code> and <code>com.openexchange.oauth.provider.rmi.jar</code>. Note that both files are symlinks. Besides the JARs you'll find the according JavaDoc in <code>/usr/share/doc/open-xchange-admin/javadoc</code> and <code>/usr/share/doc/open-xchange-oauth-provider/javadoc</code>. After adding both JARs to your classpath you can start development. The remote interface is <code>com.openexchange.oauth.provider.rmi.RemoteClientManagement</code>. Below you find an example of all operations that manipulate client data. Of course there are also methods to list and get all or certain registered clients.
Line 213:		Line 213:

	}</pre>		}</pre>

	=== SOAP Provisioning ===		=== SOAP Provisioning ===

Khgras: /* Client Provisioning */

2015-08-04T13:23:03Z

Client Provisioning

← Older revision		Revision as of 13:23, 4 August 2015
Line 43:		Line 43:

	<table>		<table>
	~~<thead>~~
	<tr>		<tr>
	<th>Parameter</th>		<th>Parameter</th>
Line 49:		Line 49:
	<th>Required</th>		<th>Required</th>
	</tr>		</tr>
	~~</thead>~~
	~~<tbody>~~
	<tr>		<tr>
	<td>name</td>		<td>name</td>
Line 86:		Line 86:
	<td>Yes</td>		<td>Yes</td>
	</tr>		</tr>
	~~</tbody>~~
	</table>		</table>
	=== RMI Provisioning ===		=== RMI Provisioning ===

Khgras: /* Client Provisioning */

2015-08-04T13:21:54Z

Client Provisioning

← Older revision		Revision as of 13:21, 4 August 2015
Line 38:		Line 38:
	For every client application that you want to allow to access the OAuth APIs you need to persist some data. During the registration call a client ID and a secret are generated, which must be provided to the client developers.		For every client application that you want to allow to access the OAuth APIs you need to persist some data. During the registration call a client ID and a secret are generated, which must be provided to the client developers.

	'''Important:''' A client does always belong to a context group and is stored within the global DB. It can therefore only handle users of the according contexts~~. See https://intranet.open-xchange.com/wiki/backend-team:globaldb for details~~. As a result you need to pass a context group name to some of the provisioning calls unless a client ID is required. After registering a client, the context group identifier is encoded within the client ID.		'''Important:''' A client does always belong to a context group and is stored within the global DB. It can therefore only handle users of the according contexts. As a result you need to pass a context group name to some of the provisioning calls unless a client ID is required. After registering a client, the context group identifier is encoded within the client ID.

	The registration data consists of the following parameters:		The registration data consists of the following parameters:

Khgras at 13:20, 4 August 2015

2015-08-04T13:20:27Z

Show changes

Khgras at 13:20, 4 August 2015

2015-08-04T13:20:05Z

← Older revision		Revision as of 13:20, 4 August 2015
Line 4:		Line 4:

	With OX App Suite v7.8.0 a service provider can decide to publish a certain subset of the OX HTTP API via OAuth 2.0. See the [[AppSuite:OAuth_2_0_Client_Developer_Guide\|developer guide]] for an overview of the available APIs. The feature as a whole is contained in separate optional packages and requires some configuration. Supported client applications must be of type <code>confidential</code> according to the <code>web application</code> profile defined in [http://tools.ietf.org/html/rfc6749 RFC 6749]. Every application must be registered at the OX backend. The registration process is up to you, while the backend provides SOAP and RMI interfaces to persist those registrations and generates the client-specific credentials that are needed to gain access for granting users.		With OX App Suite v7.8.0 a service provider can decide to publish a certain subset of the OX HTTP API via OAuth 2.0. See the [[AppSuite:OAuth_2_0_Client_Developer_Guide\|developer guide]] for an overview of the available APIs. The feature as a whole is contained in separate optional packages and requires some configuration. Supported client applications must be of type <code>confidential</code> according to the <code>web application</code> profile defined in [http://tools.ietf.org/html/rfc6749 RFC 6749]. Every application must be registered at the OX backend. The registration process is up to you, while the backend provides SOAP and RMI interfaces to persist those registrations and generates the client-specific credentials that are needed to gain access for granting users.

			== Installation and Configuration ==

			The OAuth provider feature is separated into two packages <code>open-xchange-oauth-provider</code> and <code>open-xchange-admin-oauth-provider</code>. The former one needs to be installed on every groupware node, the latter one provides the client provisioning interfaces and may be installed on your dedicated provisioning nodes. On a Debian setup you would install those packages like so:

			<pre>$ apt-get install open-xchange-oauth-provider open-xchange-admin-oauth-provider</pre>