You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+88-1Lines changed: 88 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,53 @@
1
+
# LifeWorks fork of SAML PHP
2
+
This repository is a fork from OneLogin's php-saml repository (see below)
3
+
4
+
It appears that the Master branch of the upstream repository is not how releases are managed, but in the Lifeworks repository we maintain the normal process of feature branch -> Develop -> Master for releases.
5
+
6
+
Version
7
+
-------
8
+
2022-08-22 : As part of the preparation for upgrading all PHP code bases to PHP 8.1 (and specifically wa-sso) this package has been synced with the latest changes from the upstream branch, tag version 4.1.0
9
+
10
+
Notes
11
+
-----
12
+
As at August 2022, the upstream is not considered to be under active development
13
+
14
+
https://github.com/onelogin/php-saml/issues/531
15
+
16
+
In order to make the PHPUnit tests pass, a number of changes that are maintained in the LifeWork Develop branch have been included.
17
+
18
+
Unit Testing and Static Analysis
19
+
--------------------------------
20
+
There is no Docker container for this package so PHPUnit and PHPStan must be run from the local development environment.
21
+
22
+
PHP 8.1 is required
23
+
24
+
####PHPUnit
25
+
Runs the unit tests. This includes the changes maintained within the LifeWorks Repository
26
+
```
27
+
./vendor/bin/phpunit
28
+
```
29
+
30
+
####PHPStan
31
+
PHPStan has been added as part of the PHP 8.1 and Tag 4.1 upgrade work.
Unlike most other php packages which have been added to the Lifeworks GemFury repository, php-saml was being included directly from the GitHub repository. With this upgrade, the package will be added to GemFury to bring it inline with LifeWorks best practices.
39
+
40
+
GemFury is the preferred package repository as it works for both local development and also for the CI/CD pipelines.
41
+
42
+
A ssuch, please remember to do the following when any changes are made.
43
+
44
+
Update the version in composer.json
45
+
Create a new tag and release in Github that matches the new version
46
+
Manually download the resulting release ZIP file and upload it to the Lifeworks GemFury account
@@ -148,6 +198,37 @@ environment is not secure and will be exposed to attacks.
148
198
149
199
In production also we highly recommended to register on the settings the IdP certificate instead of using the fingerprint method. The fingerprint, is a hash, so at the end is open to a collision attack that can end on a signature validation bypass. Other SAML toolkits deprecated that mechanism, we maintain it for compatibility and also to be used on test environment.
150
200
201
+
202
+
### Avoiding Open Redirect attacks ###
203
+
204
+
Some implementations uses the RelayState parameter as a way to control the flow when SSO and SLO succeeded. So basically the
205
+
user is redirected to the value of the RelayState.
206
+
207
+
If you are using Signature Validation on the HTTP-Redirect binding, you will have the RelayState value integrity covered, otherwise, and
208
+
on HTTP-POST binding, you can't trust the RelayState so before
209
+
executing the validation, you need to verify that its value belong
210
+
a trusted and expected URL.
211
+
212
+
Read more about Open Redirect [CWE-601](https://cwe.mitre.org/data/definitions/601.html).
213
+
214
+
215
+
### Avoiding Reply attacks ###
216
+
217
+
A reply attack is basically try to reuse an intercepted valid SAML Message in order to impersonate a SAML action (SSO or SLO).
218
+
219
+
SAML Messages have a limited timelife (NotBefore, NotOnOrAfter) that
220
+
make harder this kind of attacks, but they are still possible.
221
+
222
+
In order to avoid them, the SP can keep a list of SAML Messages or Assertion IDs alredy valdidated and processed. Those values only need
223
+
to be stored the amount of time of the SAML Message life time, so
224
+
we don't need to store all processed message/assertion Ids, but the most recent ones.
225
+
226
+
The OneLogin_Saml2_Auth class contains the [getLastRequestID](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L657), [getLastMessageId](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L762) and [getLastAssertionId](https://github.com/onelogin/php-saml/blob/b8214b74dd72960fa6aa88ab454667c64cea935c/src/Saml2/Auth.php#L770) methods to retrieve the IDs
227
+
228
+
Checking that the ID of the current Message/Assertion does not exists in the list of the ones already processed will prevent reply
@@ -1384,6 +1469,8 @@ Auxiliary class that contains several methods to retrieve and process IdP metada
1384
1469
*`parseXML` - Get IdP Metadata Info from XML.
1385
1470
*`injectIntoSettings` - Inject metadata info into php-saml settings array.
1386
1471
1472
+
The class does not validate in any way the URL that is introduced on methods like parseRemoteXML in order to retrieve the remove XML. Usually is the same administrator that handles the Service Provider the ones that set the URL that should belong to a trusted third-party IdP.
1473
+
But there are other scenarios, like a SAAS app where the administrator of the app delegates on other administrators. In such case, extra protection should be taken in order to validate such URL inputs and avoid attacks like SSRF.
1387
1474
1388
1475
For more info, look at the source code; each method is documented and details
1389
1476
about what it does and how to use it are provided. Make sure to also check the doc folder where
0 commit comments