Access Control - Single Sign On

Access to your website is one thing. Controlling who has access to what can be much more complex. I will use this section to create a library that will leverage directory services to control this. The concept is somewhat simple. You can use a multi-value attribute to create a delimited set of roles.
As the user accesses your application or website the initial call loads their applicable roles.
Depending on how open your site needs to be, you can stop them at the front door if they have no roles. If it is a mix of open and closed doors, you can only allow them access to specific locations or sections of a page based on their role value. It is similar to ACLs on a resource.i.e. readonly, readwrite, etc.
This method has worked across multiple domains consisting of hundreds of thousands of users with hundreds of applications, so I know it does work and I use it for all of my enterprise applications. We cross leverage it with single sign on, but if used directly you can take single sign on piece out of the picture.
The only drawback is that all applications must support use of the library, or create a webservice that they can validate against. I may head that direction anyway, since it would then allow a wider range of application support.

*This section will grow until the document is completed, step by step.
It actually only has a few moving parts.

Nutshell:
1. Library/Service:
Application library to initiate bind and pull back encrypted roles.
This will require a service account in all of the domains you are accessing.
It will contain two methods. First is called "LoadUserSettings(userObject)" and you will pass the user credentials pulled from the application connection.
The second is called "IsAllowed(int role#)" and it will call on the settings pulled from LoadUserSettings.
We will keep web service on the back burner where the applications can make a soap or rest call to retrieve the user information.
json should do the trick, though I did not build it initially with json in mind. This could be open ended where any application can retrieve
assigned roles or locked where applicaiton requires key token to access user roles. Locked would require a seperate key token control interface.

2. Role enumeration:
Roles will be based on a two part enumeration. Friendly name which will be used when handling roles and a numeric value which will be passed to the application library or via web service. Similar to 1=readonly, 2=readwrite. Each application can have it's own list of role pairs. MultiValue attributes will hold the list of application vs role values for the application and is stored on the user object. The library will load the roles at startup using the library and them using them as needed via session tokens. Each application will have its own set of roles. Storage on the user object would only be the numeric form to be passed, reducing the amount of data stored on the object. I have done this with multiple delimiters based on application requirements but that can get overly complex. If you can get application teams to conform to a specific set of role rulesets then it is much less complex. Consistency is your friend.

3. Role management web interface application.
The roles and applications will require management. This will require either a management application or website.
It will also leverage the library to control access to itself. This provides a one stop shopping for access control since it uses itself to manage itself.
It will provide a means to create new roles for each application as requested by the application development team.
Roles will also need to be applied to user objects so this will be the second step of the management interface.
I have also created it where application teams can manager their own roles as well as test role functionality pre-production rollout.
That will be of course based on your security model.

Concept:
User enters application.
Application initiates user load via svc ldap bind or web service api call, loading user role tokens. You could also pass user credentials to initiate the bind request to pass authentication as an added security step. This can get a bit more complex in multi-domain environments since it would require the user to know their account domain and authentication hops may come into play. Service accounts can allow you to bypass trust boundries.
Encrypted roles are decrypted, parsed and stored in application session, or if additioal security is required can be left encrypted and decrypted in transit.
Page elements are made visible based on role visible="isAllowed(role or token)" or as needed on callbacks.
This also allows you to use the roles as your session token to prevent man in the middle attacks. If called each time, token loss (attack) will mean an expired session. You could also add token timers by including initiated timestamps within the token itself.

I will add child pages as each piece is created and reviewed.

To be continued.