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
Version `0.8.0` changes the namespace of the gem from `Onelogin::Saml` to `Onelogin::RubySaml`. Please update your implementations of the gem accordingly.
5
+
6
+
## Overview
7
+
3
8
The Ruby SAML library is for implementing the client side of a SAML authorization, i.e. it provides a means for managing authorization initialization and confirmation requests from identity providers.
4
9
5
10
SAML authorization is a two step process and you are expected to implement support for both.
@@ -9,113 +14,113 @@ SAML authorization is a two step process and you are expected to implement suppo
9
14
This is the first request you will get from the identity provider. It will hit your application at a specific URL (that you've announced as being your SAML initialization point). The response to this initialization, is a redirect back to the identity provider, which can look something like this (ignore the saml_settings method call for now):
10
15
11
16
```ruby
12
-
definit
13
-
request =Onelogin::Saml::Authrequest.new
14
-
redirect_to(request.create(saml_settings))
15
-
end
17
+
definit
18
+
request =Onelogin::RubySaml::Authrequest.new
19
+
redirect_to(request.create(saml_settings))
20
+
end
16
21
```
17
22
18
23
Once you've redirected back to the identity provider, it will ensure that the user has been authorized and redirect back to your application for final consumption, this is can look something like this (the authorize_success and authorize_failure methods are specific to your application):
if response.is_valid? && user = current_account.users.find_by_email(response.name_id)
31
+
authorize_success(user)
32
+
else
33
+
authorize_failure(user)
34
+
end
35
+
end
31
36
```
32
37
33
38
In the above there are a few assumptions in place, one being that the response.name_id is an email address. This is all handled with how you specify the settings that are in play via the saml_settings method. That could be implemented along the lines of this:
What's left at this point, is to wrap it all up in a controller and point the initialization and consumption URLs in OneLogin at that. A full controller example could look like this:
52
57
53
58
```ruby
54
-
# This controller expects you to use the URLs /saml/init and /saml/consume in your OneLogin application.
55
-
classSamlController < ApplicationController
56
-
definit
57
-
request =Onelogin::Saml::Authrequest.new
58
-
redirect_to(request.create(saml_settings))
59
-
end
59
+
# This controller expects you to use the URLs /saml/init and /saml/consume in your OneLogin application.
To form a trusted pair relationship with the IdP, the SP (you) need to provide metadata XML
103
108
to the IdP for various good reasons. (Caching, certificate lookups, relaying party permissions, etc)
104
109
105
-
The class Onelogin::Saml::Metadata takes care of this by reading the Settings and returning XML. All
110
+
The class Onelogin::RubySaml::Metadata takes care of this by reading the Settings and returning XML. All
106
111
you have to do is add a controller to return the data, then give this URL to the IdP administrator.
107
112
The metdata will be polled by the IdP every few minutes, so updating your settings should propagate
108
113
to the IdP settings.
109
114
110
115
```ruby
111
-
classSamlController < ApplicationController
112
-
# ... the rest of your controller definitions ...
113
-
defmetadata
114
-
settings =Account.get_saml_settings
115
-
meta =Onelogin::Saml::Metadata.new
116
-
render :xml => meta.generate(settings)
117
-
end
116
+
classSamlController < ApplicationController
117
+
# ... the rest of your controller definitions ...
118
+
defmetadata
119
+
settings =Account.get_saml_settings
120
+
meta =Onelogin::RubySaml::Metadata.new
121
+
render :xml => meta.generate(settings)
118
122
end
123
+
end
119
124
```
120
125
121
126
## Clock Drift
@@ -127,7 +132,7 @@ First, ensure that both systems synchronize their clocks, using for example the
127
132
Even then you may experience intermittent issues though, because the clock of the Identity Provider may drift slightly ahead of your system clocks. To allow for a small amount of clock drift you can initialize the response passing in an option named `:allowed_clock_drift`. Its value must be given in a number (and/or fraction) of seconds. The value given is added to the current time at which the response is validated before it's tested against the `NotBefore` assertion. For example:
0 commit comments