Introduction
This sample Forum Sentry policy (attached .FSG) illustrates a very simple "self-contained" form post SSO use case utilizing HTTP session cookies. This sample is designed to teach the concepts of form post auth, HTTP session cookies, redirect policies, and User ACLs in Forum Sentry.
This sample Forum Sentry policy (attached .FSG) illustrates a very simple "self-contained" form post SSO use case utilizing HTTP session cookies. This sample is designed to teach the concepts of form post auth, HTTP session cookies, redirect policies, and User ACLs in Forum Sentry.
With this sample, the login and landing pages are hosted in Sentry rather than on a web server behind Sentry. This is great for a simple demo but not typical of actual production deployments. Instead, most environments utilize the existing web servers/pages - with these sites being accessed through Sentry - with the login page being public and the landing page being private and requiring a cookie.
Configuration and Testing
Below are the steps to import and test this sample policy. This FSG will import into any v8.7 release and later of Forum Sentry.
1. Backup your existing Sentry configuration (FSX file)
2. Import the attached HTML Policy - password is password, this will import the following policy objects:
a. HTML policy
b. Listener policy (HTTP port 8800)
c. Task List Groups (2)
d. Task Lists (2)
e. User ACL
f. Local User Group
g. Local User (testuser / password)
h. Redirect Policies (2)
i. Documents (2)
3. Using a web browser, navigate to your Sentry landing page virtual directory, something like: http://sentry_ip_or_dns_name:8800/landing - this virtual directory requires cookie auth
4. Because you are not authenticated and have no FSSESSION cookie, you'll be redirected to the login page: http://sentr_ip_or_dns_name:8800/login
5. Enter the user credentials testuser/password and click submit
6. The username/password are posted to the /auth policy in Sentry
7. Sentry will validate the credentials, set an FSSESSION cookie (configured on the Settings tab of the HTML policy), and redirect you to the landing page
8. Now when you hit the landing page, Sentry will validate the cookie and display the simple landing page
9. Use the browser developer tools to look for the FSSESSION Cookie. If you remove it and try the landing page again, you'll be redirected to /login.
10. Trace these transactions in the Access log. The success auth flow (read from bottom up) looks like this:
Conclusion
This is VERY simple Forum Sentry SSO example that utilizes HTTP form post and session cookies. A typical next step would be to integrate Sentry with an external user repository (e.g. Active Directory / LDAP) for credential validation and retrieval of user attribute information - which would be securely associated to the FSSESSION cookie for use anytime the cookie is presented for authentication.
While this sample uses form post, there are several mechanisms to authenticate to Sentry. A common method for large Active Directory shops is Kerberos Authentication, which happens all without the user having to enter any additional credentials once they've logged onto their Domain.
X.509 cert auth via SSL Termination is another commonly used means of obtaining an FSSESSION cookie from Sentry. There could also be multiple authentication mechanisms available to the user, for instance if Kerberos auth fails, redirect to a login form or prompt for basic auth credentials.
Once a Sentry FSSESSION cookie is generated it can later be used to authenticate to a Sentry STS policy (SAML 2.0 Identity Provider policy) - enabling secure SSO and federation with any local or cloud application that supports SAML. The user attributes captured during the initial authentication are securely stored in Sentry and associated to the cookie and are often used as SAML attribute values.
Sentry supports a wide array of SSO technologies so please don't hesitate to contact Forum Systems Support to discuss your specific use case requirements.
0 Comments