empayre/fleet
14
0
Fork 0
mirror of https://github.com/empayre/fleet.git synced 2024-11-07 01:15:22 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
e8def4af00
fleet/server/service/validation_app_config_test.go

73 lines
2.0 KiB
Go
Raw Normal View History

Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
package service
import (
"testing"
Add v4 suffix in go.mod (#1224)
2021-06-26 04:46:51 +00:00
"github.com/fleetdm/fleet/v4/server/fleet"
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestSSONotPresent(t *testing.T) {
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
invalid := &fleet.InvalidArgumentError{}
var p fleet.AppConfigPayload
validateSSOSettings(p, &fleet.AppConfig{}, invalid)
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
assert.False(t, invalid.HasErrors())
}
func TestNeedFieldsPresent(t *testing.T) {
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
invalid := &fleet.InvalidArgumentError{}
config := fleet.AppConfig{
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
EnableSSO: true,
Continue to update names in backend code and docs (#976)
2021-06-06 23:58:23 +00:00
EntityID: "fleet",
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
IssuerURI: "http://issuer.idp.com",
MetadataURL: "http://isser.metadata.com",
IDPName: "onelogin",
}
p := appConfigPayloadFromAppConfig(&config)
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
validateSSOSettings(*p, &fleet.AppConfig{}, invalid)
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
assert.False(t, invalid.HasErrors())
}
func TestMissingMetadata(t *testing.T) {
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
invalid := &fleet.InvalidArgumentError{}
config := fleet.AppConfig{
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
EnableSSO: true,
Continue to update names in backend code and docs (#976)
2021-06-06 23:58:23 +00:00
EntityID: "fleet",
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
IssuerURI: "http://issuer.idp.com",
IDPName: "onelogin",
}
p := appConfigPayloadFromAppConfig(&config)
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
validateSSOSettings(*p, &fleet.AppConfig{}, invalid)
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
require.True(t, invalid.HasErrors())
Refactor teams service methods (#910) - Move team-related service methods to `ee/server/service`. - Instantiate different service on startup based on license key. - Refactor service errors into separate package. - Add support for running E2E tests in both Core and Basic tiers.
2021-06-01 00:07:51 +00:00
assert.Contains(t, invalid.Error(), "metadata")
assert.Contains(t, invalid.Error(), "either metadata or metadata_url must be defined")
Server Side SSO Support (#1498) This PR partially addresses #1456, providing SSO SAML support. The flow of the code is as follows. A Kolide user attempts to access a protected resource and is directed to log in. If SSO identity providers (IDP) have been configured by an admin, the user is presented with SSO log in. The user selects SSO, which invokes a call the InitiateSSO passing the URL of the protected resource that the user was originally trying access. Kolide server loads the IDP metadata and caches it along with the URL. We then build an auth request URL for the IDP which is returned to the front end. The IDP calls the server, invoking CallbackSSO with the auth response. We extract the original request id from the response and use it to fetch the cached metadata and the URL. We check the signature of the response, and validate the timestamps. If everything passes we get the user id from the IDP response and use it to create a login session. We then build a page which executes some javascript that will write the token to web local storage, and redirect to the original URL. I've created a test web page in tools/app/authtest.html that can be used to test and debug new IDP's which also illustrates how a front end would interact with the IDP and the server. This page can be loaded by starting Kolide with the environment variable KOLIDE_TEST_PAGE_PATH to the full path of the page and then accessed at https://localhost:8080/test
2017-05-09 00:43:48 +00:00
}
Add authorization checks in service (#938) - Add policy.rego file defining authorization policies. - Add Go integrations to evaluate Rego policies (via OPA). - Add middleware to ensure requests without authorization check are rejected (guard against programmer error). - Add authorization checks to most service endpoints.
2021-06-03 23:24:15 +00:00
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
func appConfigPayloadFromAppConfig(config *fleet.AppConfig) *fleet.AppConfigPayload {
return &fleet.AppConfigPayload{
OrgInfo: &fleet.OrgInfo{
Add authorization checks in service (#938) - Add policy.rego file defining authorization policies. - Add Go integrations to evaluate Rego policies (via OPA). - Add middleware to ensure requests without authorization check are rejected (guard against programmer error). - Add authorization checks to most service endpoints.
2021-06-03 23:24:15 +00:00
OrgLogoURL: &config.OrgLogoURL,
OrgName: &config.OrgName,
},
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
ServerSettings: &fleet.ServerSettings{
Continue to update names in backend code and docs (#976)
2021-06-06 23:58:23 +00:00
ServerURL: &config.ServerURL,
Add authorization checks in service (#938) - Add policy.rego file defining authorization policies. - Add Go integrations to evaluate Rego policies (via OPA). - Add middleware to ensure requests without authorization check are rejected (guard against programmer error). - Add authorization checks to most service endpoints.
2021-06-03 23:24:15 +00:00
LiveQueryDisabled: &config.LiveQueryDisabled,
},
SMTPSettings: smtpSettingsFromAppConfig(config),
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
SSOSettings: &fleet.SSOSettingsPayload{
Add authorization checks in service (#938) - Add policy.rego file defining authorization policies. - Add Go integrations to evaluate Rego policies (via OPA). - Add middleware to ensure requests without authorization check are rejected (guard against programmer error). - Add authorization checks to most service endpoints.
2021-06-03 23:24:15 +00:00
EnableSSO: &config.EnableSSO,
IDPName: &config.IDPName,
Metadata: &config.Metadata,
MetadataURL: &config.MetadataURL,
IssuerURI: &config.IssuerURI,
EntityID: &config.EntityID,
},
Remove kolide types and packages from backend (#974) Generally renamed `kolide` -> `fleet`
2021-06-06 22:07:29 +00:00
HostExpirySettings: &fleet.HostExpirySettings{
Add authorization checks in service (#938) - Add policy.rego file defining authorization policies. - Add Go integrations to evaluate Rego policies (via OPA). - Add middleware to ensure requests without authorization check are rejected (guard against programmer error). - Add authorization checks to most service endpoints.
2021-06-03 23:24:15 +00:00
HostExpiryEnabled: &config.HostExpiryEnabled,
HostExpiryWindow: &config.HostExpiryWindow,
},
}
}
Reference in New Issue Copy Permalink