Name | aduneoclientfedid JSON |
Version |
2.0.2
JSON |
| download |
home_page | None |
Summary | Identity Federation Test Client |
upload_time | 2025-02-05 16:31:11 |
maintainer | None |
docs_url | None |
author | None |
requires_python | >=3.6 |
license | Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
|
keywords |
identity
federation
openid connect
oidc
oauth
oauth 2
saml
cas
|
VCS |
 |
bugtrack_url |
|
requirements |
build
xmlsec
python-jose
|
Travis-CI |
No Travis.
|
coveralls test coverage |
No coveralls.
|
# aduneoclientfedid
Identity Federation Test Client by Aduneo
## Quick view
**aduneoclientfedid** is used to test OpenID Connect, OAuth 2 and SAML configurations. It acts as a federation client mimicking an application.
After an initial configuration, various flows are tested. The application may obtain tokens and assertions that can be validated, then used for user info, introspection and exchange.
It is useful for:
- testing a newly installed identity provider
- learning how identity federation works
- understanding a specific feature
- debugging a faulty client configuration by replicating it
- learning how to code OpenID Connect, OAuth 2 or SAML 2
## Supported protocols
**aduneoclientfedid** supports OpenID Connect, OAuth 2 and SAML.
### OpenID Connect
The client is compatible with OpenID Connect Core 1.0 incorporating errata set 1 (https://openid.net/specs/openid-connect-core-1_0.html).
### OAuth 2
The client is compatible with
- RFC 6749 The OAuth 2.0 Authorization Framework (https://www.rfc-editor.org/rfc/rfc6749)
- RFC 7662 OAuth 2.0 Token Introspection (https://www.rfc-editor.org/rfc/rfc7662)
- RFC 8707 Resource Indicators for OAuth 2.0 (https://www.rfc-editor.org/rfc/rfc8707)
- RFC 8693 OAuth 2.0 Token Exchange (https://www.rfc-editor.org/rfc/rfc8693)
### SAML
The client is compatible with the essential parts of SAML V2.0 Specifications (http://saml.xml.org/saml-specifications)
and its use with OAuth 2 :
- RFC 7522 Security Assertion Markup Language (SAML) 2.0 Profile
for OAuth 2.0 Client Authentication and Authorization Grants (https://www.rfc-editor.org/rfc/rfc7522)
## Quick install on Windows
Not everyone is a Python expert.
If you don't have Python installed on your Windows computer, follow this procedure to quicky run ClientFedID without the need of local administrator rights:
- create a folder for ClientFedID
- download the latest WinPython distribution from https://winpython.github.io/#releases
(you only need the dot version, for exemple Winpython64-3.12.8.0dot.7z)
- unzip the file in the folder ; it will create a subfolder with a name starting with WPy64
- run WinPython Command Prompt.exe in this subfolder
(a new Windows Command window will appear)
- type
```console
> pip install aduneoclientfedid
```
- start the app with
```console
> aduneoclientfedid
```
- open your favorite browser and go to https://localhost
- a warning page will be displayed with a certificate error, which is expected
- click on *advanced* and then on *Proceed to localhost (unsafe)* or on *Accept the risk and continue* depending on your browser
- and voilà !
Attention: this version does not have SAML support. Installing SAML capabilies might prove tricky, because of the *xmlsec* library.
It is not compatible with all Python versions on Windows.
At the moment, it seems that it's working fine with Python 12 but not with Python 13.
You can try installing ClientFedID with SAML:
```console
> pip install aduneoclientfedid[saml]
```
## Installation
**aduneoclientfedid** is a web server that is installed locally, most of the time on *localhost* and accessed with a web browser.
Python must be installed on the system which will run the web server.
It is compatible with Python 3.6 and later.
It has been tested on Windows and various Linux systems. On Windows, it can be executed from a command line prompt
or in a Powershell window.
The simpliest way to install it is to download it from PyPI.
First, it is advisable to create a virtual environment in a directory where you want to install the software.
```console
$ mkdir clientfedid
$ cd clientfedid
$ python -m venv my-env
```
(depending on your operating system, you might have to use *python3* instead of *python*, or use a different command - *virtualenv -p python3 my-env* for instance)
and activate it. Depending on the system:
```console
$ source my-env/bin/activate
```
or
```console
> my-env\Script\activate
```
then install it with *pip*:
```console
$ pip install aduneoclientfedid
```
By default, packages needed for SAML are not installed, because they are tricky on some systems. If you want to use SAML,
install with the [saml] option:
```console
$ pip install aduneoclientfedid[saml]
```
You may have to manually install some Linux packages. Please refer to the xmlsec documentation (https://pypi.org/project/xmlsec)
for more information.
## Running aduneoclientfedid
Once the packages are successfully installed, create a root directory where the configuration and logs will be created.
This root directory can be located anywhere on the disk. The natural option is the directory where the Python
virtual environment (*venv*) has been created.
If you want to create a new root directory:
```console
mkdir clientfedid
cd clientfedid
```
Two directories will be created in this directory:
- *conf* where a default configuration file is generated
- *log*
Make sure the current user is allowed to create these items.
There are several ways of launching the server:
```console
clientfedid
aduneoclientfedid
python -m aduneoclientfedid
```
If successfull, a similar line is displayed:
```console
Fri Jan 6 18:15:52 2023 Server UP - https://localhost:443
```
On Unix/Linux systems, non-administrative users are prevented by default to start a server on ports below 1024.
HTTPS running on port 443, the server won't launch, with the following error:
```console
PermissionError: [Errno 13] Permission denied
```
The easiest way out is to modify the port to a value larger than 1024, for instance 8443.
To change the port, just had the *-port <port>* argument. Launching the server on port 8443 becomes:
```console
clientfedid -port 8443
```
When you use the previous command to launch the client for the first time (when the *conf* directory has not yet been created), the port is configured in the configuration file (the file *clientfedid.cnf* in the *conf* directory).
Now you don't have to specify the port in the command line for the next execution.
You can also change the listening interface, with the *-host <host>* argument.
By default, the server only listens on the *localhost* interface (127.0.0.1), meaning you can only reach it from the same computer
(with a web browser on https://localhost).
If you want to access it from another computer, you have to change the listening network interface.
To listen on any interface, run the server with an empty host:
```console
clientfedid -host ""
```
Now you can point a browser to something like https://mycomputer.domain.com.
Once the server is running, stop it with Ctrl+C.
This server is only meant to be running for the time when the tests are conducted. It is not optimized to run for a long time.
It is not optimized to run as a demon. It is definitely not secure enough.
It is usually run on the tester's computer or on a computer controlled by the tester.
## Running from sources
There are situations where it is not possible to install the server with pip.
It's still possible to run it from the sources.
First, the following packages must be manually installed:
- certifi
- charset_normalizer (at the time of writing, urllib3 is only compatible with version 2, not the newer version 3)
- idna
- urllib3
- requests
- cffi
- pycparser
- cryptography
- pyopenssl
- deprecated
- wrapt
- jwcrypto
Additionaly (for SAML):
- lxml
- xmlsec
Sources are downloaded from https://github.com/Aduneo/aduneoclientfedid, usually as a ZIP download through the *Code* button.
Create a root directory.
Create a Python virtual environment, activate it and install all necessary packages, in the order given earlier.
Unzip the sources, go to the directory containing the aduneoclientfedid folder and run:
```console
python -m aduneoclientfedid
```
## Testing OpenID Connect
**aduneoclientfedid** acts as an OpenID Connect Relaying Party (RP). It triggers user authentications, receives ID Tokens and retrieves
user information through the *userinfo* endpoint.
Once an ID token is obtained, if the RP is compatible, the token can be exchanged for an access token
(using OAuth 2.0 Token Exchange - RFC 8693).
This simulates a web application that authenticates users (OpenID Connect) and then connects to web services (OAuth 2).
### How it works
You will need
- *aduneoclientfedid* installed and started, usually on the local machine
- access to the OpenID Provider (the identity server you want to test)
- a test user created on the OpenID Provider (along with its password or any other authentication method)
- both *aduneoclientfedid* and the OP configured (more on that later)
When all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost
(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).
The browser will probably display a warning since loading a page from *localhost* is restricted when the connection is
encrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.
Once you have configured a flow with an *OpenID Provider* (as explained in the next part), you can click on the *Login* button next to the name of the configuration you wish to test.
A page is displayed with the parameters and options from the configuration. You have the liberty to change whatever you need to
perform your test. The changes only apply to the current session and leave configuration data as they are.
The authentication flow is started when you click on *Send to IdP*.
The browser is redirected to the IdP where authentication occurs. Then the browser is redirected back to *aduneoclientfedid*
with the result (success or error).
A page is displayed with the ID Token and its validation parameters (if authentification was successful).
You can then start a userinfo flow to retrieve information in the ID token.
The userinfo request is added to the page and one again you change any value before hitting *Send request*.
You can also restart an authentification flow, with the exact same parameters as the first one.
### Configuration
A configuration represents a flow between an OP and a client. Once a configuration is defined, authentications can be started.
You can define as many configurations as you want, with different OPs or with the same OP.
A new configuration is created with the *Add OIDC Client* button. A name is required. Choose any name that speaks to you, for it has
no technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.
Some parameters of the OIDC flow are configured in the OP and other in *aduneoclientfedid*.
#### OpenID Provider configuration
The OP needs the minimum following information:
- redirect URI: the *aduneoclientfedid* URL where the browser is directed after the user has been authenticated
This information is taken from the *Redirect URI* field on the *aduneoclientfedid* configuration page. The default URL is https://localhost/client/oidc/login/callback
(varies depending on configuration specifics). You can change it to suit you need. Make sure any custom URL is not used in a configuration from a different protocol
(OAuth 2 or SAML). To avoid that, it is better to add an indication about the protocol (oidc) in the URL.
Beware that you must enter the same URL in the configurations of the OP and *aduneoclientfedid*.
Some OP software automatically generate a client ID and a client secret. You need this information to configure *aduneoclientfedid*.
Other software require this information is manually entered.
Depending on the OP, additional configuration is required, for example the definition of the allowed scopes, or the authentication methods allowed for the various endpoints.
#### aduneoclientfedid configuration
*aduneoclientfedid* needs the following information:
- the OP endpoints: the URL where the browser is directed to authenticate the user and URLs for various OP web services (token retrieval, public keys, userinfo, etc.)
- client ID, identifying the client in the OP
- client secret (the password associated with the client ID)
- the method used to authenticate the client
While it is possible to detail every endpoint URL, the easiest way is to give the discovery URI, also known as the well known
configuration endpoint that returns the *configuration document* with all necessary information.
This discovery URL is the following construct: issuer URL + */.well-known/openid-configuration*.
Here are some examples:
- Azure AD: https://login.microsoftonline.com/\<IdP UID>/v2.0/.well-known/openid-configuration
- Okta: https://\<domain>.okta.com/.well-known/openid-configuration
- ForgeRock AM: https://\<server>/am/oauth2/\<realm>/.well-known/openid-configuration
- Keycloak: https://\<server>/realms/\<realm>/.well-known/openid-configuration
The client ID and client secret are either generated by the OP or entered in the OP configuration.
The authentication method describes how these credentials are transmitted:
- POST: in the HTTP body (widely used)
- Basic: in the HTTP headers
Some OPs accept any authentication method while other must be precisely configured.
#### Default parameters
When configuring an OpenID Connect service, you also provide default values for flow parameters.
The *scopes* are keywords representing information that the OP should send alongside the identity after a successfull
authentication. Multiple scopes are separated by spaces.
The parameter MUST contain *openid* per OIDC’s flow configured in the client (it distinguishes an OpenID Connect flow and an OAuth 2 flow).
The OpenID Connect Specifications define several default scopes and additional ones which can be configured in the OP.
The most used scopes for testing purposes are "openid email profile" :
- openid indicates an OpenID Connect flow
- email is obviously the email address
- profile returns basing information about the user: name, given name, gender, locale, birthdate, etc.
*aduneoclientfedid* is only compatible with the *code* response type, the implicit flow being deprecated since 2018.
#### Options
Options describe *aduneoclientfedid*'s behavior out of the OpenID Connect specifications.
The only option indicates is HTTPS certificates must be validated.
When testing a production environment, it is advised to verify certificates, to replicate the exact flows.
Other environments typically have specific certificates (self-signed or signed by an internal PKI). Since certificate verification will likely fail, it's best to disable it.
### OpenID Connect Logout
*aduneoclientfedid* implements *OpenID Connect RP-Initiated Logout 1.0*, but not yet either Front-Channel or Back-Channel.
Logout is initiated from the home page.
## Testing OAuth 2
*aduneoclientfedid* acts both as a OAuth 2 client (a web app) and a resource server (RS, ie a web service).
In a first step *aduneoclientfedid* simulates a client, triggers a user authentication and receives an access token (AT).
Then it takes the role of a resource server that would have been inkoved by the client. The RS would have received the access token and now has to validate it.
The validation method depends on the nature of the access token:
- JWTs are validated by verifying the signature (not yet implemented by *aduneoclientfedid* for ATs)
- opaque tokens must be *introspected* (presented to the introspection endpoint for validation and user information retrieval)
*aduneoclientfedid* performs token exchanges (RFC 8693) to get other access tokens or ID tokens from an access token. At the time of writing very few AS have implemented this RFC.
OAuth 2 flows (introspections and token exchanges) can also be initiated after a SAML authentication.
### How it works
You will need
- *aduneoclientfedid* installed and started, usually on the local machine
- access to the Authorization Server (the identity server you want to test)
- a test user created on the Authorization server (along with its password or any other authentication method)
- both *aduneoclientfedid* and the OP configured (more on that later)
When all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost
(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).
The browser will probably display a warning since loading a page from *localhost* is restricted when the connection is
encrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.
Once you have configured a flow with an *authorization server* (as explained in the next part), you can click on the *Login* button next to the name of the configuration you wish to test.
A page is displayed with the parameters and options from the configuration. You have the liberty to change whatever you need to
perform your test. The changes only apply to the current session and leave configuration data as they are.
The authentication flow is started when you click on *Send to IdP*.
The browser is redirected to the AS where authentication occurs. Then the browser is redirected back to *aduneoclientfedid*
with the result (success or error).
A page is displayed with the Access Token.
Then, you can start an introspection flow or a token exchange flow.
### Configuration
A configuration represents a flow between an Authorization Server and a client. Once a configuration is defined, authorizations can be started.
You can define as many configurations as you want, with different ASs or with the same AS.
A new configuration is created with the *Add OAuth Client* button. A name is required. Choose any name that speaks to you, for it has
no technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.
Some parameters of the OAuth 2 flow are configured in the OP and other in aduneoclientfedid.
#### Authorization Server configuration
The AS needs the minimum following information:
- redirect URI: the *aduneoclientfedid* URL where the browser is directed after the user has been authenticated
This information is taken from the *Redirect URI* field on the *aduneoclientfedid* configuration page. The default URL is https://localhost/client/oidc/login/callback
(varies depending on configuration specifics). You can change it to suit you need. Make sure any custom URL is not used in a configuration from a different protocol
(OIDC or SAML). To avoid that, it is better to add an indication about the protocol (oidc) in the URL.
Beware that you must enter the same URL in the configurations of the OP and *aduneoclientfedid*.
Some AS software automatically generate a client ID and a client secret. You need this information to configure *aduneoclientfedid*. Other software require this information is manually entered.
Depending on the AS, additional configuration is required, for example the definition of the allowed scopes, or the authentication methods allowed for the various endpoints.
If introspection is used for validating the AT, you need to create a configuration for *aduneoclientfedid* acting as a resource server. All is needed is a login and a secret.
Each authorization server software has its own configuration way
- some have dedicated objects to represent a RS
- others treat RS as clients with minimal configuration
Refer to the software documentation to determine how to proceed.
#### aduneoclientfedid configuration
The *aduneoclientfedid* configuration page is split in 2 sections:
- "Token request by the client" is the configuration when it acts as a client
- "Token validation by the API (resource server)" when it acts as a resource server
To obtain an Access Token, the following information is needed:
- the AS endpoints: URL where the browser is directed to authenticate the user and URLs for various AS web services (token retrieval, introspection, etc.)
- client ID, identifying the client in the AS
- client secret (the password associated with the client ID)
- the method used to authenticate the client
OAuth does not have a discovery URI mechanism like OpenID Connect, where the client can retrieve all endpoints (and additional parameters).
Normally, each individual endpoint must be provided.
But some AS software publish a discovery URI, which can be the same as OpenID Connect, or different. If it's different, make sure to enter the correct URI. Otherwise
you might have an unpredictable behavior.
This is the case with Okta :
- https://\<domain>.okta.com/.well-known/oauth-authorization-server
ForgeRock AM has the same discovery URI for OpenID Connect and OAuth 2.
The client ID and client secret are either generated by the AS or entered in the AS configuration.
The authentication method describes how these credentials are transmitted:
- POST: in the HTTP body (widely used)
- Basic: in the HTTP headers
Some Authorization Servers accept any authentication method while other must be precisely configured.
If tokens are validated by introspection, you can configure how to perform it:
- introspection endpoint (if not retrieved through the discovery URI)
- resource server client ID: the login used by the web service that has received the Access Token
- resource server secret: the corresponding secret (*aduneoclientfedid* is only compatible with a password at the moment)
#### Default parameters
When configuring an OAuth 2 service, you also provide default values for flow parameters.
The *scopes* are keywords representing the type of access that is requested. They are entirely dependent on your own installation. They usually represent access types (read, write, create, delete, etc.).
The *resource* parameter is defined by RFC 8707 but not implemented by many AS. Check compatibility before using it.
*aduneoclientfedid* is only compatible with the *code* response type, the implicit flow being deprecated since 2018.
#### Options
Options describe *aduneoclientfedid*'s behavior outside of the OAuth RFCs.
The only option indicates if HTTPS certificates must be validated.
When testing a production environment, it is advised to verify certificates, to replicate the exact flows.
Other environments typically have specific certificates (self-signed or signed by an internal PKI). Since certificate verification will likely fail, it's best to disable it.
### Access Token Introspection
After an access token has been obtained, it can be introspected.
After clicking on the "Introspect AT" button, a form is displayed in two parts:
- first the parameters defined by RFC 7662 (token and token type hint)
- then the request as it is going to be sent to the authorization server: endpoint, data, authentication parameters
Any change in the first part is reflected on the second (but not the other war around).
During tests, you'll probably have to enter the same information many times (credentials for instance). To help you with that, you can use the internal clipboard.
It keeps all inputs that are entered so that you just have to select it when it's needed again.
The clipboard is opened when clicking the icon on the right of each form field.
By default, passwords are not stored in the clipboard, but a configuration parameter enables this feature.
### Refreshing Access Tokens
If a refresh token (RT) was retrieved during OAuth flow, it can be used to get a new access token.
As with introspection, a two-part form is displayed:
- top form: parameters defined by RFC 6749 (section 6)
- bottom form: the request as it will be sent to the authorization server
### Token Exchange
RFC 8693 defines a way to obtain a new token (ID or access) from an existing valid token (ID or access).
Few authorization servers have implemented it, so check it's available.
## Testing SAML 2
*aduneoclientfedid* is a SAML 2 Service Provider (SP). It simulates an application authenticating to an Identity Provider (IdP).
SAML authentication is only available when the *xmlsec* Python module is installed. Refer to this page for instruction on how to install it: https://pypi.org/project/xmlsec/.
Sometimes it's easy (Windows) sometimes it requires some skills (Ubuntu).
After a successful authentication an OAuth 2 Access Token can be obtained when the IdP is compatible with RFC 7522
(*Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants*).
### How it works
You will need
- *aduneoclientfedid* installed and started, usually on the local machine
- access to the Identity Provider (the identity server you want to test)
- a test user created on the IdP (along with its password or any other authentication method)
- both *aduneoclientfedid* and the IdP correctly configured (more on that later)
When all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost
(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).
The browser will probably display a warning since loading a page from *localhost* is restricted when the connection is
encrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.
Once you configured a flow in the client as explained in the next part, you can click on the *Login* button next to the name of the configuration you wish to test.
A page is displayed with the default configuration and the default options. You have the liberty to change whatever you need to
perform your test.
The authentication flow is started when you click on *Send to IdP*.
The browser is redirected to the IdP where authentication occurs. Then the browser is redirected to *aduneoclientfedid*.
A page is displayed with the SAML assertion and its validation parameters.
You can then retrieve an access token if needed (and if the IdP is RFC 7522 compliant).
### Configuration
A configuration represents a flow between an Identity Provider and a client. Once a configuration is defined, authentications can be started.
You can define as many configurations as you want, with different IdPs or with the same IdP.
A new configuration is created with the *Add SAML SP* button. A name is required. Choose any name that speaks to you, for it has
no technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.
A SAML configuration is an exchange of metadata files :
- the SP generates an XML file that is uploaded to the IdP
- the IdP generates an XML file that is uploaded to the SP
While this is the easy way to proceed, it is still possible to enter each parameter individually.
Having gathered information from the IdP, you configure *aduneoclientfedid*
- either by uploading the metadata file, which results in the parameter fields being automatically populated
- or by manually entering it: entity ID, SSO URL and certificate (optionally Single Logout URL)
The certificate must be in PEM format, with or without a header and a footer.
*aduneoclientfedid* generates an XML metadata file based on the information provided in the form:
- SP Entity ID: references the SP. It must be a URI, it is recommended it is a URL
- SP Assertion Consumer Service (ACS) URL: callback URL to *aduneoclientfedid* after authentication. Default is https://localhost/client/saml/login/acs, but you can change it (as long as it stays in the same domain).
- keys and certificate: this information is used to sign the requests. You can either use the default key or provide your own
(in case you want to replicate an exact real world behavior). Communicate the certificate but **NOT the private key**.
- NameID policy: expected user identifier field returned in the SAML assertion
- Authentication binding: method used to send an authentication request
- Logout binding (optional): method used to send a logout request
Those values are communicated to the IdP either manually or via a metadata file (downloaded through the *Download SP metadata* button)
There obviously needs to be a coherence between the configurations of the SP and the IdP.
Many problems arise because of incompatible NameID policies. NameID is the field with the user's identity. SAML defines different formats and different values.
The easiest format to configure would be the email (*urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress*), but it is not always the best choice for an identifier
(actually, it's a pretty terrible choice in most cases). A better option is an uid present in the identity repository of the organization, which has to be conveyed
in the unspecified format (*urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified*). It often requires a specific configuration on the IdP part.
### SAML Logout
*aduneoclientfedid* implements Single Logout, with the POST or Redirect bindings.
Logout is initiated from the home page.
## General configuration
Some configuration parameters affecting the server behaviour are modified in the configuration file, using your
favorite editor. There is no web console now for these parameters.
The configuration file is named clientfedid.cnf and is in the conf directory that has been created in the current folder
(the one from which the python command has been issued).
It's a JSON file, so be careful of trailing commas. As a reminder, the following syntax is not permitted by JSON:
```console
{
"param1": "value1",
"param2": "this will result in an error",
}
```
(remove the last comma to make it JSON compliant)
There are 6 main sections in the configuration file:
- meta: information about the configuration file itself. It only contains the name of the file containing the key used to encrypt
passwords
- server: HTTP server parameters (port, SSL, etc.)
- preferences
- oidc_clients, oauth_clients, saml_clients: these parts detail the various clients and configurations in the application
Any manual change in thre configuration file requires the server to be restarted (Ctrl-C then clientfedid/aduneoclientfedid/python -m aduneoclientfedid).
### meta/key: encryption key file name
All parameters with a name ending with an exclamation point (!) are automatically encrypted (client secrets), using a symmetric key.
A key is automatically generated at first launch and store in a file named clientfedid.key.
It is a good practice to protect this file.
### server/host
Identifies the network card used by the HTTP server.
Using the default localhost makes sure no other machine is (easily...) able to access it.
An empty value ("") opens it to anyone (depending on your local firewall settings).
It can be a name or an IP address.
### server/port
Listening port for the HTTP server.
Default is 443. It might not work on Unix/Linux systems. The easiest fix is to choose a port number greater than 1024 (8443 is a good
candidate).
### server/ssl
Activates HTTPS. Possible values are *on* and *off*.
Since most of the security of OpenID Connect/OAuth 2 relies on HTTPS, it is advisable to leave the default (*on*).
But you may have to turn it off for testing purposes.
### server/ssl_key_file and server/ssl_cert_file
When SSL is activated, these parameters contains the file with
- the SSL private key (*ssl_key_file*), PEM format
- the associated certificate (*ssl_cert_file*), PEM format
If those files are not referenced in the configuration file (which is the default), aduneoclientfedid will automatically create
a key and certificate. Those items are deleted after the server is stopped.
The certificate is self-signed, with server/host as the subject (the FQDN of the machine if server/host is empty).
### preferences/logging/handler
List of logging handlers:
- console: displays logs in the window used to launch the server
- file: adds logs in a file in a directory (*logs*) created alongside *conf* directory.
- webconsole: displays logs in a browser window that can be opened by "console" button on the upper right side of the page, or
automatically when an authentication flow is started
By default, all handlers are activated.
### preferences/open_webconsole:
*on* if the browser window displaying logs is automatically opened every time an authentication flow is started (default).
### preferences/clipboard/encrypt_clipboard
The clipboard stores all texts typed in application forms, to be easily used multiple times without having to enter them each time.
Its content is stored in the *conf* directory.
If *encrypt_clipboard* is *on*, the file is encrypted using *clientfedid.key* as a key. This is the default.
Otherwise, its content is in plain text.
### preferences/clipboard/remember_secrets
Indicates if secrets are stored in the clipboard (default is *off*).
Raw data
{
"_id": null,
"home_page": null,
"name": "aduneoclientfedid",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.6",
"maintainer_email": null,
"keywords": "identity, federation, openid connect, oidc, oauth, oauth 2, saml, cas",
"author": null,
"author_email": "Aduneo <contact@aduneo.com>",
"download_url": "https://files.pythonhosted.org/packages/b1/96/207c9b11cc09e8e0779bd5481ccdfb7ef1e48fa8e1f5634a1f18af9b9987/aduneoclientfedid-2.0.2.tar.gz",
"platform": null,
"description": "# aduneoclientfedid\r\nIdentity Federation Test Client by Aduneo\r\n\r\n## Quick view\r\n\r\n**aduneoclientfedid** is used to test OpenID Connect, OAuth 2 and SAML configurations. It acts as a federation client mimicking an application.\r\n\r\nAfter an initial configuration, various flows are tested. The application may obtain tokens and assertions that can be validated, then used for user info, introspection and exchange.\r\n\r\nIt is useful for:\r\n- testing a newly installed identity provider\r\n- learning how identity federation works\r\n- understanding a specific feature\r\n- debugging a faulty client configuration by replicating it\r\n- learning how to code OpenID Connect, OAuth 2 or SAML 2\r\n\r\n\r\n## Supported protocols\r\n\r\n**aduneoclientfedid** supports OpenID Connect, OAuth 2 and SAML.\r\n\r\n### OpenID Connect\r\n\r\nThe client is compatible with OpenID Connect Core 1.0 incorporating errata set 1 (https://openid.net/specs/openid-connect-core-1_0.html).\r\n\r\n### OAuth 2\r\n\r\nThe client is compatible with\r\n- RFC 6749 The OAuth 2.0 Authorization Framework (https://www.rfc-editor.org/rfc/rfc6749)\r\n- RFC 7662 OAuth 2.0 Token Introspection (https://www.rfc-editor.org/rfc/rfc7662)\r\n- RFC 8707 Resource Indicators for OAuth 2.0 (https://www.rfc-editor.org/rfc/rfc8707)\r\n- RFC 8693 OAuth 2.0 Token Exchange (https://www.rfc-editor.org/rfc/rfc8693)\r\n\r\n### SAML\r\n\r\nThe client is compatible with the essential parts of SAML V2.0 Specifications (http://saml.xml.org/saml-specifications)\r\n\r\nand its use with OAuth 2 :\r\n- RFC 7522 Security Assertion Markup Language (SAML) 2.0 Profile\r\n for OAuth 2.0 Client Authentication and Authorization Grants (https://www.rfc-editor.org/rfc/rfc7522)\r\n\r\n\r\n## Quick install on Windows\r\n\r\nNot everyone is a Python expert.\r\n\r\nIf you don't have Python installed on your Windows computer, follow this procedure to quicky run ClientFedID without the need of local administrator rights:\r\n- create a folder for ClientFedID\r\n- download the latest WinPython distribution from https://winpython.github.io/#releases\r\n (you only need the dot version, for exemple Winpython64-3.12.8.0dot.7z)\r\n- unzip the file in the folder ; it will create a subfolder with a name starting with WPy64\r\n- run WinPython Command Prompt.exe in this subfolder\r\n (a new Windows Command window will appear)\r\n- type \r\n```console\r\n> pip install aduneoclientfedid\r\n```\r\n- start the app with\r\n```console\r\n> aduneoclientfedid\r\n```\r\n- open your favorite browser and go to https://localhost\r\n- a warning page will be displayed with a certificate error, which is expected\r\n- click on *advanced* and then on *Proceed to localhost (unsafe)* or on *Accept the risk and continue* depending on your browser\r\n- and voil\u00e0 !\r\n\r\nAttention: this version does not have SAML support. Installing SAML capabilies might prove tricky, because of the *xmlsec* library. \r\nIt is not compatible with all Python versions on Windows.\r\n\r\nAt the moment, it seems that it's working fine with Python 12 but not with Python 13.\r\n\r\nYou can try installing ClientFedID with SAML:\r\n```console\r\n> pip install aduneoclientfedid[saml]\r\n```\r\n\r\n\r\n## Installation\r\n\r\n**aduneoclientfedid** is a web server that is installed locally, most of the time on *localhost* and accessed with a web browser.\r\n\r\nPython must be installed on the system which will run the web server.\r\nIt is compatible with Python 3.6 and later.\r\n\r\nIt has been tested on Windows and various Linux systems. On Windows, it can be executed from a command line prompt\r\nor in a Powershell window.\r\n\r\nThe simpliest way to install it is to download it from PyPI.\r\n\r\nFirst, it is advisable to create a virtual environment in a directory where you want to install the software.\r\n```console\r\n$ mkdir clientfedid\r\n$ cd clientfedid\r\n$ python -m venv my-env\r\n```\r\n(depending on your operating system, you might have to use *python3* instead of *python*, or use a different command - *virtualenv -p python3 my-env* for instance)\r\n\r\nand activate it. Depending on the system:\r\n```console\r\n$ source my-env/bin/activate\r\n```\r\nor\r\n```console\r\n> my-env\\Script\\activate\r\n```\r\nthen install it with *pip*:\r\n```console\r\n$ pip install aduneoclientfedid\r\n```\r\nBy default, packages needed for SAML are not installed, because they are tricky on some systems. If you want to use SAML,\r\ninstall with the [saml] option:\r\n```console\r\n$ pip install aduneoclientfedid[saml]\r\n```\r\n\r\nYou may have to manually install some Linux packages. Please refer to the xmlsec documentation (https://pypi.org/project/xmlsec)\r\nfor more information.\r\n\r\n\r\n## Running aduneoclientfedid\r\n\r\nOnce the packages are successfully installed, create a root directory where the configuration and logs will be created. \r\nThis root directory can be located anywhere on the disk. The natural option is the directory where the Python\r\nvirtual environment (*venv*) has been created.\r\n\r\nIf you want to create a new root directory:\r\n```console\r\nmkdir clientfedid\r\ncd clientfedid\r\n```\r\n\r\nTwo directories will be created in this directory:\r\n- *conf* where a default configuration file is generated\r\n- *log*\r\n\r\nMake sure the current user is allowed to create these items.\r\n\r\nThere are several ways of launching the server:\r\n```console\r\nclientfedid\r\naduneoclientfedid\r\npython -m aduneoclientfedid\r\n```\r\nIf successfull, a similar line is displayed:\r\n```console\r\nFri Jan 6 18:15:52 2023 Server UP - https://localhost:443\r\n```\r\n\r\nOn Unix/Linux systems, non-administrative users are prevented by default to start a server on ports below 1024.\r\n\r\nHTTPS running on port 443, the server won't launch, with the following error:\r\n```console\r\nPermissionError: [Errno 13] Permission denied\r\n```\r\n\r\nThe easiest way out is to modify the port to a value larger than 1024, for instance 8443.\r\n\r\nTo change the port, just had the *-port <port>* argument. Launching the server on port 8443 becomes:\r\n```console\r\nclientfedid -port 8443\r\n```\r\n\r\nWhen you use the previous command to launch the client for the first time (when the *conf* directory has not yet been created), the port is configured in the configuration file (the file *clientfedid.cnf* in the *conf* directory).\r\nNow you don't have to specify the port in the command line for the next execution.\r\n\r\nYou can also change the listening interface, with the *-host <host>* argument.\r\n\r\nBy default, the server only listens on the *localhost* interface (127.0.0.1), meaning you can only reach it from the same computer\r\n(with a web browser on https://localhost).\r\nIf you want to access it from another computer, you have to change the listening network interface.\r\n\r\nTo listen on any interface, run the server with an empty host:\r\n```console\r\nclientfedid -host \"\"\r\n```\r\nNow you can point a browser to something like https://mycomputer.domain.com.\r\n\r\nOnce the server is running, stop it with Ctrl+C.\r\n\r\nThis server is only meant to be running for the time when the tests are conducted. It is not optimized to run for a long time.\r\nIt is not optimized to run as a demon. It is definitely not secure enough.\r\n\r\nIt is usually run on the tester's computer or on a computer controlled by the tester.\r\n\r\n\r\n## Running from sources\r\n\r\nThere are situations where it is not possible to install the server with pip.\r\n\r\nIt's still possible to run it from the sources.\r\n\r\nFirst, the following packages must be manually installed:\r\n- certifi\r\n- charset_normalizer (at the time of writing, urllib3 is only compatible with version 2, not the newer version 3)\r\n- idna\r\n- urllib3\r\n- requests\r\n- cffi\r\n- pycparser\r\n- cryptography\r\n- pyopenssl\r\n- deprecated\r\n- wrapt\r\n- jwcrypto\r\n\r\nAdditionaly (for SAML):\r\n- lxml\r\n- xmlsec\r\n\r\nSources are downloaded from https://github.com/Aduneo/aduneoclientfedid, usually as a ZIP download through the *Code* button.\r\n\r\nCreate a root directory.\r\n\r\nCreate a Python virtual environment, activate it and install all necessary packages, in the order given earlier.\r\n\r\nUnzip the sources, go to the directory containing the aduneoclientfedid folder and run:\r\n```console\r\npython -m aduneoclientfedid\r\n```\r\n\r\n\r\n## Testing OpenID Connect\r\n\r\n**aduneoclientfedid** acts as an OpenID Connect Relaying Party (RP). It triggers user authentications, receives ID Tokens and retrieves\r\nuser information through the *userinfo* endpoint.\r\n\r\nOnce an ID token is obtained, if the RP is compatible, the token can be exchanged for an access token\r\n(using OAuth 2.0 Token Exchange - RFC 8693).\r\nThis simulates a web application that authenticates users (OpenID Connect) and then connects to web services (OAuth 2).\r\n\r\n### How it works\r\n\r\nYou will need\r\n- *aduneoclientfedid* installed and started, usually on the local machine\r\n- access to the OpenID Provider (the identity server you want to test)\r\n- a test user created on the OpenID Provider (along with its password or any other authentication method)\r\n- both *aduneoclientfedid* and the OP configured (more on that later)\r\n\r\nWhen all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost\r\n(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).\r\n\r\nThe browser will probably display a warning since loading a page from *localhost* is restricted when the connection is\r\nencrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.\r\n\r\nOnce you have configured a flow with an *OpenID Provider* (as explained in the next part), you can click on the *Login* button next to the name of the configuration you wish to test.\r\n\r\nA page is displayed with the parameters and options from the configuration. You have the liberty to change whatever you need to\r\nperform your test. The changes only apply to the current session and leave configuration data as they are.\r\n\r\nThe authentication flow is started when you click on *Send to IdP*.\r\n\r\nThe browser is redirected to the IdP where authentication occurs. Then the browser is redirected back to *aduneoclientfedid*\r\nwith the result (success or error).\r\n\r\nA page is displayed with the ID Token and its validation parameters (if authentification was successful).\r\n\r\nYou can then start a userinfo flow to retrieve information in the ID token.\r\n\r\nThe userinfo request is added to the page and one again you change any value before hitting *Send request*.\r\n\r\nYou can also restart an authentification flow, with the exact same parameters as the first one.\r\n\r\n\r\n### Configuration\r\n\r\nA configuration represents a flow between an OP and a client. Once a configuration is defined, authentications can be started.\r\n\r\nYou can define as many configurations as you want, with different OPs or with the same OP.\r\n\r\nA new configuration is created with the *Add OIDC Client* button. A name is required. Choose any name that speaks to you, for it has\r\nno technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.\r\n\r\nSome parameters of the OIDC flow are configured in the OP and other in *aduneoclientfedid*.\r\n\r\n#### OpenID Provider configuration\r\n\r\nThe OP needs the minimum following information:\r\n- redirect URI: the *aduneoclientfedid* URL where the browser is directed after the user has been authenticated\r\n\r\nThis information is taken from the *Redirect URI* field on the *aduneoclientfedid* configuration page. The default URL is https://localhost/client/oidc/login/callback \r\n(varies depending on configuration specifics). You can change it to suit you need. Make sure any custom URL is not used in a configuration from a different protocol\r\n(OAuth 2 or SAML). To avoid that, it is better to add an indication about the protocol (oidc) in the URL. \r\nBeware that you must enter the same URL in the configurations of the OP and *aduneoclientfedid*.\r\n\r\nSome OP software automatically generate a client ID and a client secret. You need this information to configure *aduneoclientfedid*.\r\nOther software require this information is manually entered.\r\n\r\nDepending on the OP, additional configuration is required, for example the definition of the allowed scopes, or the authentication methods allowed for the various endpoints.\r\n\r\n#### aduneoclientfedid configuration\r\n\r\n*aduneoclientfedid* needs the following information:\r\n- the OP endpoints: the URL where the browser is directed to authenticate the user and URLs for various OP web services (token retrieval, public keys, userinfo, etc.)\r\n- client ID, identifying the client in the OP\r\n- client secret (the password associated with the client ID)\r\n- the method used to authenticate the client\r\n\r\nWhile it is possible to detail every endpoint URL, the easiest way is to give the discovery URI, also known as the well known\r\nconfiguration endpoint that returns the *configuration document* with all necessary information.\r\n\r\nThis discovery URL is the following construct: issuer URL + */.well-known/openid-configuration*.\r\n\r\nHere are some examples:\r\n- Azure AD: https://login.microsoftonline.com/\\<IdP UID>/v2.0/.well-known/openid-configuration\r\n- Okta: https://\\<domain>.okta.com/.well-known/openid-configuration\r\n- ForgeRock AM: https://\\<server>/am/oauth2/\\<realm>/.well-known/openid-configuration\r\n- Keycloak: https://\\<server>/realms/\\<realm>/.well-known/openid-configuration\r\n\r\nThe client ID and client secret are either generated by the OP or entered in the OP configuration.\r\n\r\nThe authentication method describes how these credentials are transmitted:\r\n- POST: in the HTTP body (widely used)\r\n- Basic: in the HTTP headers\r\n\r\nSome OPs accept any authentication method while other must be precisely configured.\r\n\r\n#### Default parameters\r\n\r\nWhen configuring an OpenID Connect service, you also provide default values for flow parameters.\r\n\r\nThe *scopes* are keywords representing information that the OP should send alongside the identity after a successfull\r\nauthentication. Multiple scopes are separated by spaces.\r\n\r\nThe parameter MUST contain *openid* per OIDC\u2019s flow configured in the client (it distinguishes an OpenID Connect flow and an OAuth 2 flow).\r\n\r\nThe OpenID Connect Specifications define several default scopes and additional ones which can be configured in the OP.\r\n\r\nThe most used scopes for testing purposes are \"openid email profile\" :\r\n- openid indicates an OpenID Connect flow\r\n- email is obviously the email address\r\n- profile returns basing information about the user: name, given name, gender, locale, birthdate, etc.\r\n\r\n*aduneoclientfedid* is only compatible with the *code* response type, the implicit flow being deprecated since 2018.\r\n\r\n#### Options\r\n\r\nOptions describe *aduneoclientfedid*'s behavior out of the OpenID Connect specifications.\r\n\r\nThe only option indicates is HTTPS certificates must be validated.\r\n\r\nWhen testing a production environment, it is advised to verify certificates, to replicate the exact flows.\r\n\r\nOther environments typically have specific certificates (self-signed or signed by an internal PKI). Since certificate verification will likely fail, it's best to disable it.\r\n\r\n\r\n### OpenID Connect Logout\r\n\r\n*aduneoclientfedid* implements *OpenID Connect RP-Initiated Logout 1.0*, but not yet either Front-Channel or Back-Channel.\r\n\r\nLogout is initiated from the home page.\r\n\r\n\r\n## Testing OAuth 2\r\n\r\n*aduneoclientfedid* acts both as a OAuth 2 client (a web app) and a resource server (RS, ie a web service).\r\n\r\nIn a first step *aduneoclientfedid* simulates a client, triggers a user authentication and receives an access token (AT).\r\nThen it takes the role of a resource server that would have been inkoved by the client. The RS would have received the access token and now has to validate it.\r\n\r\nThe validation method depends on the nature of the access token:\r\n- JWTs are validated by verifying the signature (not yet implemented by *aduneoclientfedid* for ATs)\r\n- opaque tokens must be *introspected* (presented to the introspection endpoint for validation and user information retrieval)\r\n\r\n*aduneoclientfedid* performs token exchanges (RFC 8693) to get other access tokens or ID tokens from an access token. At the time of writing very few AS have implemented this RFC.\r\n\r\nOAuth 2 flows (introspections and token exchanges) can also be initiated after a SAML authentication.\r\n\r\n### How it works\r\n\r\nYou will need\r\n- *aduneoclientfedid* installed and started, usually on the local machine\r\n- access to the Authorization Server (the identity server you want to test)\r\n- a test user created on the Authorization server (along with its password or any other authentication method)\r\n- both *aduneoclientfedid* and the OP configured (more on that later)\r\n\r\nWhen all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost\r\n(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).\r\n\r\nThe browser will probably display a warning since loading a page from *localhost* is restricted when the connection is\r\nencrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.\r\n\r\nOnce you have configured a flow with an *authorization server* (as explained in the next part), you can click on the *Login* button next to the name of the configuration you wish to test.\r\n\r\nA page is displayed with the parameters and options from the configuration. You have the liberty to change whatever you need to\r\nperform your test. The changes only apply to the current session and leave configuration data as they are.\r\n\r\nThe authentication flow is started when you click on *Send to IdP*.\r\n\r\nThe browser is redirected to the AS where authentication occurs. Then the browser is redirected back to *aduneoclientfedid*\r\nwith the result (success or error).\r\n\r\nA page is displayed with the Access Token.\r\n\r\nThen, you can start an introspection flow or a token exchange flow.\r\n\r\n### Configuration\r\n\r\nA configuration represents a flow between an Authorization Server and a client. Once a configuration is defined, authorizations can be started.\r\n\r\nYou can define as many configurations as you want, with different ASs or with the same AS.\r\n\r\nA new configuration is created with the *Add OAuth Client* button. A name is required. Choose any name that speaks to you, for it has\r\nno technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.\r\n\r\nSome parameters of the OAuth 2 flow are configured in the OP and other in aduneoclientfedid.\r\n\r\n#### Authorization Server configuration\r\n\r\nThe AS needs the minimum following information:\r\n- redirect URI: the *aduneoclientfedid* URL where the browser is directed after the user has been authenticated\r\n\r\nThis information is taken from the *Redirect URI* field on the *aduneoclientfedid* configuration page. The default URL is https://localhost/client/oidc/login/callback \r\n(varies depending on configuration specifics). You can change it to suit you need. Make sure any custom URL is not used in a configuration from a different protocol\r\n(OIDC or SAML). To avoid that, it is better to add an indication about the protocol (oidc) in the URL. \r\nBeware that you must enter the same URL in the configurations of the OP and *aduneoclientfedid*.\r\n\r\nSome AS software automatically generate a client ID and a client secret. You need this information to configure *aduneoclientfedid*. Other software require this information is manually entered.\r\n\r\nDepending on the AS, additional configuration is required, for example the definition of the allowed scopes, or the authentication methods allowed for the various endpoints.\r\n\r\nIf introspection is used for validating the AT, you need to create a configuration for *aduneoclientfedid* acting as a resource server. All is needed is a login and a secret.\r\nEach authorization server software has its own configuration way\r\n- some have dedicated objects to represent a RS\r\n- others treat RS as clients with minimal configuration\r\nRefer to the software documentation to determine how to proceed.\r\n\r\n#### aduneoclientfedid configuration\r\n\r\nThe *aduneoclientfedid* configuration page is split in 2 sections:\r\n- \"Token request by the client\" is the configuration when it acts as a client\r\n- \"Token validation by the API (resource server)\" when it acts as a resource server\r\n\r\nTo obtain an Access Token, the following information is needed:\r\n- the AS endpoints: URL where the browser is directed to authenticate the user and URLs for various AS web services (token retrieval, introspection, etc.)\r\n- client ID, identifying the client in the AS\r\n- client secret (the password associated with the client ID)\r\n- the method used to authenticate the client\r\n\r\nOAuth does not have a discovery URI mechanism like OpenID Connect, where the client can retrieve all endpoints (and additional parameters).\r\nNormally, each individual endpoint must be provided.\r\n\r\nBut some AS software publish a discovery URI, which can be the same as OpenID Connect, or different. If it's different, make sure to enter the correct URI. Otherwise \r\nyou might have an unpredictable behavior.\r\n\r\nThis is the case with Okta :\r\n- https://\\<domain>.okta.com/.well-known/oauth-authorization-server\r\n\r\nForgeRock AM has the same discovery URI for OpenID Connect and OAuth 2.\r\n\r\nThe client ID and client secret are either generated by the AS or entered in the AS configuration.\r\n\r\nThe authentication method describes how these credentials are transmitted:\r\n- POST: in the HTTP body (widely used)\r\n- Basic: in the HTTP headers\r\n\r\nSome Authorization Servers accept any authentication method while other must be precisely configured.\r\n\r\nIf tokens are validated by introspection, you can configure how to perform it:\r\n- introspection endpoint (if not retrieved through the discovery URI)\r\n- resource server client ID: the login used by the web service that has received the Access Token\r\n- resource server secret: the corresponding secret (*aduneoclientfedid* is only compatible with a password at the moment)\r\n\r\n#### Default parameters\r\n\r\nWhen configuring an OAuth 2 service, you also provide default values for flow parameters.\r\n\r\nThe *scopes* are keywords representing the type of access that is requested. They are entirely dependent on your own installation. They usually represent access types (read, write, create, delete, etc.).\r\n\r\nThe *resource* parameter is defined by RFC 8707 but not implemented by many AS. Check compatibility before using it.\r\n\r\n*aduneoclientfedid* is only compatible with the *code* response type, the implicit flow being deprecated since 2018.\r\n\r\n#### Options\r\n\r\nOptions describe *aduneoclientfedid*'s behavior outside of the OAuth RFCs.\r\n\r\nThe only option indicates if HTTPS certificates must be validated.\r\n\r\nWhen testing a production environment, it is advised to verify certificates, to replicate the exact flows.\r\n\r\nOther environments typically have specific certificates (self-signed or signed by an internal PKI). Since certificate verification will likely fail, it's best to disable it.\r\n\r\n### Access Token Introspection\r\n\r\nAfter an access token has been obtained, it can be introspected.\r\n\r\nAfter clicking on the \"Introspect AT\" button, a form is displayed in two parts:\r\n- first the parameters defined by RFC 7662 (token and token type hint)\r\n- then the request as it is going to be sent to the authorization server: endpoint, data, authentication parameters\r\n\r\nAny change in the first part is reflected on the second (but not the other war around).\r\n\r\nDuring tests, you'll probably have to enter the same information many times (credentials for instance). To help you with that, you can use the internal clipboard.\r\nIt keeps all inputs that are entered so that you just have to select it when it's needed again.\r\nThe clipboard is opened when clicking the icon on the right of each form field.\r\nBy default, passwords are not stored in the clipboard, but a configuration parameter enables this feature.\r\n\r\n### Refreshing Access Tokens\r\n\r\nIf a refresh token (RT) was retrieved during OAuth flow, it can be used to get a new access token.\r\n\r\nAs with introspection, a two-part form is displayed:\r\n- top form: parameters defined by RFC 6749 (section 6)\r\n- bottom form: the request as it will be sent to the authorization server\r\n\r\n### Token Exchange\r\n\r\nRFC 8693 defines a way to obtain a new token (ID or access) from an existing valid token (ID or access).\r\n\r\nFew authorization servers have implemented it, so check it's available.\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n## Testing SAML 2\r\n\r\n*aduneoclientfedid* is a SAML 2 Service Provider (SP). It simulates an application authenticating to an Identity Provider (IdP).\r\n\r\nSAML authentication is only available when the *xmlsec* Python module is installed. Refer to this page for instruction on how to install it: https://pypi.org/project/xmlsec/.\r\nSometimes it's easy (Windows) sometimes it requires some skills (Ubuntu).\r\n\r\nAfter a successful authentication an OAuth 2 Access Token can be obtained when the IdP is compatible with RFC 7522 \r\n(*Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants*).\r\n\r\n### How it works\r\n\r\nYou will need\r\n- *aduneoclientfedid* installed and started, usually on the local machine\r\n- access to the Identity Provider (the identity server you want to test)\r\n- a test user created on the IdP (along with its password or any other authentication method)\r\n- both *aduneoclientfedid* and the IdP correctly configured (more on that later)\r\n\r\nWhen all of this is done, connect with a web browser to *aduneoclientfedid* main page. Usually https://localhost\r\n(it's possible to install it on a different machine, to change to port, and to deactivate HTTPS for testing purposes).\r\n\r\nThe browser will probably display a warning since loading a page from *localhost* is restricted when the connection is\r\nencrypted. Bypass the warning, or change the configuration to switch to unencrypted or to connect to a real IP address.\r\n\r\nOnce you configured a flow in the client as explained in the next part, you can click on the *Login* button next to the name of the configuration you wish to test.\r\n\r\nA page is displayed with the default configuration and the default options. You have the liberty to change whatever you need to\r\nperform your test.\r\n\r\nThe authentication flow is started when you click on *Send to IdP*.\r\n\r\nThe browser is redirected to the IdP where authentication occurs. Then the browser is redirected to *aduneoclientfedid*.\r\n\r\nA page is displayed with the SAML assertion and its validation parameters.\r\n\r\nYou can then retrieve an access token if needed (and if the IdP is RFC 7522 compliant).\r\n\r\n### Configuration\r\n\r\nA configuration represents a flow between an Identity Provider and a client. Once a configuration is defined, authentications can be started.\r\n\r\nYou can define as many configurations as you want, with different IdPs or with the same IdP.\r\n\r\nA new configuration is created with the *Add SAML SP* button. A name is required. Choose any name that speaks to you, for it has\r\nno technical meaning. It is obviously advised that the name includes references to the OP and to what you are to test.\r\n\r\nA SAML configuration is an exchange of metadata files :\r\n- the SP generates an XML file that is uploaded to the IdP\r\n- the IdP generates an XML file that is uploaded to the SP\r\n\r\nWhile this is the easy way to proceed, it is still possible to enter each parameter individually.\r\n\r\nHaving gathered information from the IdP, you configure *aduneoclientfedid*\r\n- either by uploading the metadata file, which results in the parameter fields being automatically populated\r\n- or by manually entering it: entity ID, SSO URL and certificate (optionally Single Logout URL)\r\nThe certificate must be in PEM format, with or without a header and a footer.\r\n\r\n*aduneoclientfedid* generates an XML metadata file based on the information provided in the form:\r\n- SP Entity ID: references the SP. It must be a URI, it is recommended it is a URL\r\n- SP Assertion Consumer Service (ACS) URL: callback URL to *aduneoclientfedid* after authentication. Default is https://localhost/client/saml/login/acs, but you can change it (as long as it stays in the same domain).\r\n- keys and certificate: this information is used to sign the requests. You can either use the default key or provide your own \r\n(in case you want to replicate an exact real world behavior). Communicate the certificate but **NOT the private key**.\r\n- NameID policy: expected user identifier field returned in the SAML assertion\r\n- Authentication binding: method used to send an authentication request\r\n- Logout binding (optional): method used to send a logout request\r\n\r\nThose values are communicated to the IdP either manually or via a metadata file (downloaded through the *Download SP metadata* button)\r\n\r\nThere obviously needs to be a coherence between the configurations of the SP and the IdP.\r\n\r\nMany problems arise because of incompatible NameID policies. NameID is the field with the user's identity. SAML defines different formats and different values.\r\nThe easiest format to configure would be the email (*urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress*), but it is not always the best choice for an identifier\r\n(actually, it's a pretty terrible choice in most cases). A better option is an uid present in the identity repository of the organization, which has to be conveyed\r\nin the unspecified format (*urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified*). It often requires a specific configuration on the IdP part.\r\n\r\n### SAML Logout\r\n\r\n*aduneoclientfedid* implements Single Logout, with the POST or Redirect bindings.\r\n\r\nLogout is initiated from the home page.\r\n\r\n\r\n\r\n\r\n\r\n## General configuration\r\n\r\nSome configuration parameters affecting the server behaviour are modified in the configuration file, using your\r\nfavorite editor. There is no web console now for these parameters.\r\n\r\nThe configuration file is named clientfedid.cnf and is in the conf directory that has been created in the current folder\r\n(the one from which the python command has been issued).\r\n\r\nIt's a JSON file, so be careful of trailing commas. As a reminder, the following syntax is not permitted by JSON:\r\n```console\r\n{\r\n \"param1\": \"value1\",\r\n \"param2\": \"this will result in an error\",\r\n}\r\n```\r\n(remove the last comma to make it JSON compliant)\r\n\r\nThere are 6 main sections in the configuration file:\r\n- meta: information about the configuration file itself. It only contains the name of the file containing the key used to encrypt\r\n passwords\r\n- server: HTTP server parameters (port, SSL, etc.)\r\n- preferences\r\n- oidc_clients, oauth_clients, saml_clients: these parts detail the various clients and configurations in the application\r\n\r\nAny manual change in thre configuration file requires the server to be restarted (Ctrl-C then clientfedid/aduneoclientfedid/python -m aduneoclientfedid).\r\n\r\n### meta/key: encryption key file name\r\n\r\nAll parameters with a name ending with an exclamation point (!) are automatically encrypted (client secrets), using a symmetric key.\r\n\r\nA key is automatically generated at first launch and store in a file named clientfedid.key.\r\n\r\nIt is a good practice to protect this file.\r\n\r\n### server/host\r\n\r\nIdentifies the network card used by the HTTP server.\r\n\r\nUsing the default localhost makes sure no other machine is (easily...) able to access it.\r\n\r\nAn empty value (\"\") opens it to anyone (depending on your local firewall settings).\r\n\r\nIt can be a name or an IP address.\r\n\r\n### server/port\r\n\r\nListening port for the HTTP server.\r\n\r\nDefault is 443. It might not work on Unix/Linux systems. The easiest fix is to choose a port number greater than 1024 (8443 is a good\r\ncandidate).\r\n\r\n### server/ssl\r\n\r\nActivates HTTPS. Possible values are *on* and *off*.\r\n\r\nSince most of the security of OpenID Connect/OAuth 2 relies on HTTPS, it is advisable to leave the default (*on*).\r\n\r\nBut you may have to turn it off for testing purposes.\r\n\r\n### server/ssl_key_file and server/ssl_cert_file\r\n\r\nWhen SSL is activated, these parameters contains the file with\r\n- the SSL private key (*ssl_key_file*), PEM format\r\n- the associated certificate (*ssl_cert_file*), PEM format\r\n\r\nIf those files are not referenced in the configuration file (which is the default), aduneoclientfedid will automatically create\r\na key and certificate. Those items are deleted after the server is stopped.\r\n\r\nThe certificate is self-signed, with server/host as the subject (the FQDN of the machine if server/host is empty).\r\n\r\n### preferences/logging/handler\r\n\r\nList of logging handlers:\r\n- console: displays logs in the window used to launch the server\r\n- file: adds logs in a file in a directory (*logs*) created alongside *conf* directory.\r\n- webconsole: displays logs in a browser window that can be opened by \"console\" button on the upper right side of the page, or\r\nautomatically when an authentication flow is started\r\n\r\nBy default, all handlers are activated.\r\n\r\n### preferences/open_webconsole:\r\n\r\n*on* if the browser window displaying logs is automatically opened every time an authentication flow is started (default).\r\n\r\n### preferences/clipboard/encrypt_clipboard\r\n\r\nThe clipboard stores all texts typed in application forms, to be easily used multiple times without having to enter them each time.\r\n\r\nIts content is stored in the *conf* directory.\r\n\r\nIf *encrypt_clipboard* is *on*, the file is encrypted using *clientfedid.key* as a key. This is the default.\r\n\r\nOtherwise, its content is in plain text.\r\n\r\n### preferences/clipboard/remember_secrets\r\n\r\nIndicates if secrets are stored in the clipboard (default is *off*).\r\n",
"bugtrack_url": null,
"license": "Apache License\r\n Version 2.0, January 2004\r\n http://www.apache.org/licenses/\r\n \r\n TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\r\n \r\n 1. Definitions.\r\n \r\n \"License\" shall mean the terms and conditions for use, reproduction,\r\n and distribution as defined by Sections 1 through 9 of this document.\r\n \r\n \"Licensor\" shall mean the copyright owner or entity authorized by\r\n the copyright owner that is granting the License.\r\n \r\n \"Legal Entity\" shall mean the union of the acting entity and all\r\n other entities that control, are controlled by, or are under common\r\n control with that entity. For the purposes of this definition,\r\n \"control\" means (i) the power, direct or indirect, to cause the\r\n direction or management of such entity, whether by contract or\r\n otherwise, or (ii) ownership of fifty percent (50%) or more of the\r\n outstanding shares, or (iii) beneficial ownership of such entity.\r\n \r\n \"You\" (or \"Your\") shall mean an individual or Legal Entity\r\n exercising permissions granted by this License.\r\n \r\n \"Source\" form shall mean the preferred form for making modifications,\r\n including but not limited to software source code, documentation\r\n source, and configuration files.\r\n \r\n \"Object\" form shall mean any form resulting from mechanical\r\n transformation or translation of a Source form, including but\r\n not limited to compiled object code, generated documentation,\r\n and conversions to other media types.\r\n \r\n \"Work\" shall mean the work of authorship, whether in Source or\r\n Object form, made available under the License, as indicated by a\r\n copyright notice that is included in or attached to the work\r\n (an example is provided in the Appendix below).\r\n \r\n \"Derivative Works\" shall mean any work, whether in Source or Object\r\n form, that is based on (or derived from) the Work and for which the\r\n editorial revisions, annotations, elaborations, or other modifications\r\n represent, as a whole, an original work of authorship. For the purposes\r\n of this License, Derivative Works shall not include works that remain\r\n separable from, or merely link (or bind by name) to the interfaces of,\r\n the Work and Derivative Works thereof.\r\n \r\n \"Contribution\" shall mean any work of authorship, including\r\n the original version of the Work and any modifications or additions\r\n to that Work or Derivative Works thereof, that is intentionally\r\n submitted to Licensor for inclusion in the Work by the copyright owner\r\n or by an individual or Legal Entity authorized to submit on behalf of\r\n the copyright owner. For the purposes of this definition, \"submitted\"\r\n means any form of electronic, verbal, or written communication sent\r\n to the Licensor or its representatives, including but not limited to\r\n communication on electronic mailing lists, source code control systems,\r\n and issue tracking systems that are managed by, or on behalf of, the\r\n Licensor for the purpose of discussing and improving the Work, but\r\n excluding communication that is conspicuously marked or otherwise\r\n designated in writing by the copyright owner as \"Not a Contribution.\"\r\n \r\n \"Contributor\" shall mean Licensor and any individual or Legal Entity\r\n on behalf of whom a Contribution has been received by Licensor and\r\n subsequently incorporated within the Work.\r\n \r\n 2. Grant of Copyright License. Subject to the terms and conditions of\r\n this License, each Contributor hereby grants to You a perpetual,\r\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\r\n copyright license to reproduce, prepare Derivative Works of,\r\n publicly display, publicly perform, sublicense, and distribute the\r\n Work and such Derivative Works in Source or Object form.\r\n \r\n 3. Grant of Patent License. Subject to the terms and conditions of\r\n this License, each Contributor hereby grants to You a perpetual,\r\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\r\n (except as stated in this section) patent license to make, have made,\r\n use, offer to sell, sell, import, and otherwise transfer the Work,\r\n where such license applies only to those patent claims licensable\r\n by such Contributor that are necessarily infringed by their\r\n Contribution(s) alone or by combination of their Contribution(s)\r\n with the Work to which such Contribution(s) was submitted. If You\r\n institute patent litigation against any entity (including a\r\n cross-claim or counterclaim in a lawsuit) alleging that the Work\r\n or a Contribution incorporated within the Work constitutes direct\r\n or contributory patent infringement, then any patent licenses\r\n granted to You under this License for that Work shall terminate\r\n as of the date such litigation is filed.\r\n \r\n 4. Redistribution. You may reproduce and distribute copies of the\r\n Work or Derivative Works thereof in any medium, with or without\r\n modifications, and in Source or Object form, provided that You\r\n meet the following conditions:\r\n \r\n (a) You must give any other recipients of the Work or\r\n Derivative Works a copy of this License; and\r\n \r\n (b) You must cause any modified files to carry prominent notices\r\n stating that You changed the files; and\r\n \r\n (c) You must retain, in the Source form of any Derivative Works\r\n that You distribute, all copyright, patent, trademark, and\r\n attribution notices from the Source form of the Work,\r\n excluding those notices that do not pertain to any part of\r\n the Derivative Works; and\r\n \r\n (d) If the Work includes a \"NOTICE\" text file as part of its\r\n distribution, then any Derivative Works that You distribute must\r\n include a readable copy of the attribution notices contained\r\n within such NOTICE file, excluding those notices that do not\r\n pertain to any part of the Derivative Works, in at least one\r\n of the following places: within a NOTICE text file distributed\r\n as part of the Derivative Works; within the Source form or\r\n documentation, if provided along with the Derivative Works; or,\r\n within a display generated by the Derivative Works, if and\r\n wherever such third-party notices normally appear. The contents\r\n of the NOTICE file are for informational purposes only and\r\n do not modify the License. You may add Your own attribution\r\n notices within Derivative Works that You distribute, alongside\r\n or as an addendum to the NOTICE text from the Work, provided\r\n that such additional attribution notices cannot be construed\r\n as modifying the License.\r\n \r\n You may add Your own copyright statement to Your modifications and\r\n may provide additional or different license terms and conditions\r\n for use, reproduction, or distribution of Your modifications, or\r\n for any such Derivative Works as a whole, provided Your use,\r\n reproduction, and distribution of the Work otherwise complies with\r\n the conditions stated in this License.\r\n \r\n 5. Submission of Contributions. Unless You explicitly state otherwise,\r\n any Contribution intentionally submitted for inclusion in the Work\r\n by You to the Licensor shall be under the terms and conditions of\r\n this License, without any additional terms or conditions.\r\n Notwithstanding the above, nothing herein shall supersede or modify\r\n the terms of any separate license agreement you may have executed\r\n with Licensor regarding such Contributions.\r\n \r\n 6. Trademarks. This License does not grant permission to use the trade\r\n names, trademarks, service marks, or product names of the Licensor,\r\n except as required for reasonable and customary use in describing the\r\n origin of the Work and reproducing the content of the NOTICE file.\r\n \r\n 7. Disclaimer of Warranty. Unless required by applicable law or\r\n agreed to in writing, Licensor provides the Work (and each\r\n Contributor provides its Contributions) on an \"AS IS\" BASIS,\r\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\r\n implied, including, without limitation, any warranties or conditions\r\n of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\r\n PARTICULAR PURPOSE. You are solely responsible for determining the\r\n appropriateness of using or redistributing the Work and assume any\r\n risks associated with Your exercise of permissions under this License.\r\n \r\n 8. Limitation of Liability. In no event and under no legal theory,\r\n whether in tort (including negligence), contract, or otherwise,\r\n unless required by applicable law (such as deliberate and grossly\r\n negligent acts) or agreed to in writing, shall any Contributor be\r\n liable to You for damages, including any direct, indirect, special,\r\n incidental, or consequential damages of any character arising as a\r\n result of this License or out of the use or inability to use the\r\n Work (including but not limited to damages for loss of goodwill,\r\n work stoppage, computer failure or malfunction, or any and all\r\n other commercial damages or losses), even if such Contributor\r\n has been advised of the possibility of such damages.\r\n \r\n 9. Accepting Warranty or Additional Liability. While redistributing\r\n the Work or Derivative Works thereof, You may choose to offer,\r\n and charge a fee for, acceptance of support, warranty, indemnity,\r\n or other liability obligations and/or rights consistent with this\r\n License. However, in accepting such obligations, You may act only\r\n on Your own behalf and on Your sole responsibility, not on behalf\r\n of any other Contributor, and only if You agree to indemnify,\r\n defend, and hold each Contributor harmless for any liability\r\n incurred by, or claims asserted against, such Contributor by reason\r\n of your accepting any such warranty or additional liability.\r\n \r\n END OF TERMS AND CONDITIONS\r\n \r\n APPENDIX: How to apply the Apache License to your work.\r\n \r\n To apply the Apache License to your work, attach the following\r\n boilerplate notice, with the fields enclosed by brackets \"[]\"\r\n replaced with your own identifying information. (Don't include\r\n the brackets!) The text should be enclosed in the appropriate\r\n comment syntax for the file format. We also recommend that a\r\n file or class name and description of purpose be included on the\r\n same \"printed page\" as the copyright notice for easier\r\n identification within third-party archives.\r\n \r\n Copyright [yyyy] [name of copyright owner]\r\n \r\n Licensed under the Apache License, Version 2.0 (the \"License\");\r\n you may not use this file except in compliance with the License.\r\n You may obtain a copy of the License at\r\n \r\n http://www.apache.org/licenses/LICENSE-2.0\r\n \r\n Unless required by applicable law or agreed to in writing, software\r\n distributed under the License is distributed on an \"AS IS\" BASIS,\r\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\r\n See the License for the specific language governing permissions and\r\n limitations under the License.\r\n ",
"summary": "Identity Federation Test Client",
"version": "2.0.2",
"project_urls": {
"homepage": "https://www.aduneo.com",
"repository": "https://github.com/Aduneo/aduneoclientfedid"
},
"split_keywords": [
"identity",
" federation",
" openid connect",
" oidc",
" oauth",
" oauth 2",
" saml",
" cas"
],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "35581bc1bc6ffb6874067bb9704119df556d076d1ac686f9888260352eff2895",
"md5": "c05a52e68a2f4faec614538acc303a73",
"sha256": "d064f908ac93e6fcedeccd4a2a7418d02982ab198f5049a78869fb56859a271b"
},
"downloads": -1,
"filename": "aduneoclientfedid-2.0.2-py3-none-any.whl",
"has_sig": false,
"md5_digest": "c05a52e68a2f4faec614538acc303a73",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.6",
"size": 538455,
"upload_time": "2025-02-05T16:31:07",
"upload_time_iso_8601": "2025-02-05T16:31:07.385640Z",
"url": "https://files.pythonhosted.org/packages/35/58/1bc1bc6ffb6874067bb9704119df556d076d1ac686f9888260352eff2895/aduneoclientfedid-2.0.2-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "b196207c9b11cc09e8e0779bd5481ccdfb7ef1e48fa8e1f5634a1f18af9b9987",
"md5": "d93dadab1561c4528c60eaca19edab7f",
"sha256": "1707f1ccb98bc5ed2cef222326fff9dbc5d4478f3cd6a948d7ee021967faeb46"
},
"downloads": -1,
"filename": "aduneoclientfedid-2.0.2.tar.gz",
"has_sig": false,
"md5_digest": "d93dadab1561c4528c60eaca19edab7f",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.6",
"size": 506370,
"upload_time": "2025-02-05T16:31:11",
"upload_time_iso_8601": "2025-02-05T16:31:11.798967Z",
"url": "https://files.pythonhosted.org/packages/b1/96/207c9b11cc09e8e0779bd5481ccdfb7ef1e48fa8e1f5634a1f18af9b9987/aduneoclientfedid-2.0.2.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-02-05 16:31:11",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "Aduneo",
"github_project": "aduneoclientfedid",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"requirements": [
{
"name": "build",
"specs": []
},
{
"name": "xmlsec",
"specs": []
},
{
"name": "python-jose",
"specs": []
}
],
"lcname": "aduneoclientfedid"
}