This is something I like to do once in a while. It takes long time to setup everything but to me it is a hobby. It is like putting zigsaw puzzles.

WARNING: THIS IS NOT SUPPORTED! THIS IS ONLY TO FULFILL YOUR CURIOSITY AND SATISFY YOUR SPIRIT GOING AGAINST ALL ODDS. THIS IS NOT A DEMONSTRATION ALLOWING YOU TO RUN SUCH CONFIGURATION IN YOUR DEV/TEST/QA/PROD ENVIRONMENT.

Following configuration will be setup.

01. Basic setup - Create application and protect using Forms Authentication.

     - Service configuration

     - Startup/Shutdown scripts

     - Logging

     - Basic Concepts

02. Standard Authentication Schemes

     - Basic Concepts

     - Basic

     - HTML Forms

     - HTML using UID and EMAIL

     - Basic over SSL

03. Certificate Authentication Schemes

     - X.509 Certificate Only

     - X.509 Certificate or Basic

     - X.509 Certificate and Basic

     - X.509 Certificate or Form

     - X.509 Certificate and Form

04. Windows Authentication Scheme

05. OAuth Authentication Scheme

06. Cookie Provider

07. Directory Mapping

08. Password Services

09. Impersonation

10. Session Assurance

11. SAML 2.0 Partnership Federation - SSO

12. SAML 2.0 Partnership Federation - SLO

13. SAML 2.0 Partnership Federation - RelayState

14. SAML 2.0 Partnership Federation - Negative Assertion

15. SAML 1.x Partnership Federation

16. Audit Log import

17. Generating Reports

18. SiteMinder Test Tool

19. Global Delivery Modules

20. Troubleshooting

01. Basic setup - Create application and protect using Forms Authentication.

     - Basic Concepts

This is continuing from Part 1 where we were creating basic objects to protect a resource.

Next is creating a Domain.

Navigate to "AdminUI ==> Policies ==> Domain ==> Domains" and click on "Create Domain".

Enter the required field.

Name: "www.sso.lab"

This is just a name, it does not need to reflect your FQHN of your web server.

You can just name it "Test1" as well.

But to me it is easier to use the FQHN.

Now, you can see that the first thing you do with this Domain is to link a User Directory.

That is the reason why you must have a User Directory configured first.

Click on "Add/Remove" under User Directories.

Select "SSO LAB Domain Users" from the left pane and move it to the right pane by clicking on the "arrow" button and click "OK".

Then click on "Realms" tab and click on "Create Realm" button.

Enter required Fields.

Name : Basic Realm

Agent: agent.iis

Resource Filter: /basic/

Authentication Scheme: Basic

Scroll down and click "Create" for Rules.

Enter required fields.

Name: Access Basic

Resource: *

Scroll down and select Action: Get and Post

Then click "OK

Click on "Policies" tab and click "Create".

Entered the required fields.

Name: Basic Policy

Then click on the "Users" tab.

In general, if you click on "Add Members" it will present you with a list where you can choose from.

But if it does not give you the desired list, then you can enter manually by clicking on "Add Entry".

I choose, "Validate DN" because I just want to check if the user is found to be within this DN.

Click "OK" and click on "Rules" tab.

As the Rule is already created, click on "Add Rule".

You will be presented with a list to choose from.

Check "Basic Realm" and click "OK".

Click "OK" and you will.back at "Policies". Click "Submit"

This is how you protect a resource using "Domain" type

.

What you configured is:

You created a User directory that contains user who you want to grant access.

Then you created an Authentication Scheme, how the users will be submitting their credentials to prove their identity.

Then you created a Domain and linked the User directory.

You created a Realm for "/basic/" URI to protect it.

Then you linked the Authentication Scheme to the Realm so when users acess /basic/ they will be prompted with Basic Authentication.

In the same Realm, you created Rules for "GET" and "POST" Method/Action.

This means requests that are submitted to /basic/ Realm are evaluated for authorization only for the GET and POST requests. Other requests are all rejected.

You have created a Policy to link those Rules and added "CN=Users,DC=SSO,DC=LAB" for authorization.

What this means is that, if the user is found to be located within this "CN=Users,DC=SSO,DC=LAB", they will be authorized. Others will be rejected.

So, in simple terms, you are creating all these to "Authorize" the user for resources.

Now, if you access "http://www.sso.lab/basic/" then you will get challenged as below.

From the Basic prompt, you can see it is saying "The server reports that it is from Basic Realm".

This shows it is from SiteMinder and not the web server because it is saying the resource is "Basic Realm" which is the Realm Name we entered.

Let's login as "smuser"

You can see above that "smuser" is logged on as the "USERNAME" shows "smuser".

You can also find "SMSESSION" cookie.

If you scroll down, you can also see the user is accessing "Basic Realm".

The User Directory is "SSO LAB Domain Users".

UserDN is "CN=smuser,CN=Users,DC=sso,DC=lab".

Now, access "http://www.sso.lab/logout/" which in previous configuration we have defined "/logout/" as "LogoffURI".

You can see "USERNAME" no longer shows "smuser" and the SMSESSION cookie has value of "LOGGEDOFF".

You have successfully logged out.

If you go to "http://www.sso.lab/basic/" you will be prompted to enter user credential again.

Now, I am going to delete all the configuration and show you how to create the same using "Application" type.

To delete all the configuration, goto "AdminUI ==> Policies ==> Domain ==> Domains".

Select "www.sso.lab" and click on the "X" button at the right end.

This will delete everything but not the "User Directory" and "Authentication Scheme" because they are stand-alone objects and not a child object belonging to a domain. They are only referenced objects.

Now, let's perform the same thing using "Application".

Goto "AdminUI ==> Policies ==> Application ==> Applications" and click "Create Application"

You should be familiar with all the information displayed here.

Enter the required fields.

Name: www.sso.lab

Component Name: Basic Realm

Agent: agent.iis

Resource Filter: /basic/

Authentication Scheme: Basic

User Directory: SSO LAB Domain Users.

Then navigate to "Resources" tab and click "Create".

Enter required fields.

Name: Access Basic

Action: Get and Post

Then navigate to "Roles" tab and click "Create Role".

Scroll down to "Advanced ==> User Expression" and enter the following.

     (AT("CN=Users,DC=sso,DC=lab",SM_USERDN))

In general, SiteMinder will list all the groups and OU and O for you to choose from.

But this "CN=Users" is a unique use case because it is a user container but is not using OU.

So, that is the reason why it was not listed when you were trying to create a Policy in the Domain.

You are faced with the same problem here as well.

For this specific use case, or any similar special conditions, you can enter the expression manually as above.

That that expression means is, if the user is "AT" the "CN=Users,DC=sso,DC=lab" based on the UserDN, then the user matches this role.

This "AT" condition means you must be exactly at the "CN=Users", not further below.

If the UserDN is "CN=User1,OU=ABC,CN=Users,DC=sso,DC=lab" then the user does not match this role. <== You must remember this!

Click on the "Validate" button to ensure there is no typo error.

Navigate to "Policies" tab. Check the "Basic Role" for "Access Basic" Resource and then click "Submit"

Now you have protected /basic/ using Application mode.

Goto "http://www.sso.lab/basic/" and logon as smuser.

You can see all the information is the same as when you protected this resource using Domain or Application.

I hope this gave you a good comparison of both.

They are the same, just slight difference as Role is introduced.

I will not delete this Application. I will be adding more Components(Realms) to this Application.

Next article will be creating Authentication Schemes.

Stay tuned!!!

This concludes "Configuring an ALL-IN-ONE VM Image - Part 2"