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
+79Lines changed: 79 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -172,6 +172,12 @@ This folder contains a Bottle project that will be used as demo to show how to a
172
172
173
173
This folder contains a Flask project that will be used as demo to show how to add SAML support to the Flask Framework. 'index.py' is the main flask file that has all the code, this file uses the templates stored at the 'templates' folder. In the 'saml' folder we found the 'certs' folder to store the x509 public and private key, and the saml toolkit settings (settings.json and advanced_settings.json).
174
174
175
+
176
+
#### demo_pyramid ####
177
+
178
+
This folder contains a Pyramid project that will be used as demo to show how to add SAML support to the [Pyramid Web Framework](http://docs.pylonsproject.org/projects/pyramid/en/latest/). '\_\_init__.py' is the main file that configures the app and its routes, 'views.py' is where all the logic and SAML handling takes place, and the templates are stored in the 'templates' folder. The 'saml' folder is the same as in the other two demos.
179
+
180
+
175
181
#### setup.py ####
176
182
177
183
Setup script is the centre of all activity in building, distributing, and installing modules.
@@ -1145,3 +1151,76 @@ Once the SP is configured, the metadata of the SP is published at the /metadata
1145
1151
####How it works####
1146
1152
1147
1153
This demo works very similar to the flask-demo (We did it intentionally).
1154
+
1155
+
1156
+
### Demo Pyramid ###
1157
+
1158
+
Unlike the other two projects, you don't need a pre-existing virtualenv to get
1159
+
up and running here, since Pyramid comes from the
1160
+
[buildout](http://www.buildout.org/en/latest/) school of thought.
1161
+
1162
+
To run the demo you need to install Pyramid, the requirements, etc.:
1163
+
```
1164
+
cd demo_pyramid
1165
+
python -m venv env
1166
+
env/bin/pip install --upgrade pip setuptools
1167
+
env/bin/pip install -e ".[testing]"
1168
+
```
1169
+
1170
+
Next, edit the settings in `demo_pyramid/saml/settings.json`. (Pyramid runs on
1171
+
port 6543 by default.)
1172
+
1173
+
Now you can run the demo like this:
1174
+
```
1175
+
env/bin/pserve development.ini
1176
+
```
1177
+
1178
+
If that worked, the demo is now running at http://localhost:6543.
1179
+
1180
+
####Content####
1181
+
1182
+
The Pyramid project contains:
1183
+
1184
+
1185
+
****\_\_init__.py*** is the main Pyramid file that configures the app and its routes.
1186
+
1187
+
****views.py*** is where all the SAML handling takes place.
1188
+
1189
+
****templates*** is the folder where Pyramid stores the templates of the project. It was implemented a layout.jinja2 template that is extended by index.jinja2 and attrs.jinja2, the templates of our simple demo that shows messages, user attributes when available and login and logout links.
1190
+
1191
+
****saml*** is a folder that contains the 'certs' folder that could be used to store the x509 public and private key, and the saml toolkit settings (settings.json and advanced_settings.json).
1192
+
1193
+
1194
+
####SP setup####
1195
+
1196
+
The Onelogin's Python Toolkit allows you to provide the settings info in 2 ways: settings files or define a setting dict. In demo_pyramid the first method is used.
1197
+
1198
+
In the views.py file we define the SAML_PATH, which will target the 'saml' folder. We require it in order to load the settings files.
1199
+
1200
+
First we need to edit the saml/settings.json, configure the SP part and review the metadata of the IdP and complete the IdP info. Later edit the saml/advanced_settings.json files and configure the how the toolkit will work. Check the settings section of this document if you have any doubt.
1201
+
1202
+
####IdP setup####
1203
+
1204
+
Once the SP is configured, the metadata of the SP is published at the /metadata/ url. Based on that info, configure the IdP.
1205
+
1206
+
####How it works####
1207
+
1208
+
1. First time you access to the main view 'http://localhost:6543', you can select to login and return to the same view or login and be redirected to /?attrs (attrs view).
1209
+
1210
+
2. When you click:
1211
+
1212
+
2.1 in the first link, we access to /?sso (index view). An AuthNRequest is sent to the IdP, we authenticate at the IdP and then a Response is sent through the user's client to the SP, specifically the Assertion Consumer Service view: /?acs. Notice that a RelayState parameter is set to the url that initiated the process, the index view.
1213
+
1214
+
2.2 in the second link we access to /?attrs (attrs view), we will expetience have the same process described at 2.1 with the diference that as RelayState is set the attrs url.
1215
+
1216
+
3. The SAML Response is processed in the ACS /?acs, if the Response is not valid, the process stops here and a message is shown. Otherwise we are redirected to the RelayState view. a) / or b) /?attrs
1217
+
1218
+
4. We are logged in the app and the user attributes are showed. At this point, we can test the single log out functionality.
1219
+
1220
+
The single log out funcionality could be tested by 2 ways.
1221
+
1222
+
5.1 SLO Initiated by SP. Click on the "logout" link at the SP, after that a Logout Request is sent to the IdP, the session at the IdP is closed and replies through the client to the SP with a Logout Response (sent to the Single Logout Service endpoint). The SLS endpoint /?sls of the SP process the Logout Response and if is valid, close the user session of the local app. Notice that the SLO Workflow starts and ends at the SP.
1223
+
1224
+
5.2 SLO Initiated by IdP. In this case, the action takes place on the IdP side, the logout process is initiated at the IdP, sends a Logout Request to the SP (SLS endpoint, /?sls). The SLS endpoint of the SP process the Logout Request and if is valid, close the session of the user at the local app and send a Logout Response to the IdP (to the SLS endpoint of the IdP). The IdP receives the Logout Response, process it and close the session at of the IdP. Notice that the SLO Workflow starts and ends at the IdP.
1225
+
1226
+
Notice that all the SAML Requests and Responses are handled at a unique view (index) and how GET parameters are used to know the action that must be done.
0 commit comments