|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (1)
View page history... |
| This is covered in the article, [Protecting Java EE Applications With OpenSSO Policy Agents, Part 2: Same-Domain SSO| http://developers.sun.com/identity/reference/techart/policyagents2.html] |
h3. Some optional steps Want to learn some more? If you already got the sample apps above working with simple SSO, now maybe try a few more things... * if you want to allow anonymous access so any user can access certain pages then you can try out some other agent configuration to set certain URLs as *not enforced* by the agent, so then no sign on is required to access them. See the J2EE agent property com.sun.identity.agents.config.notenforced.uri list and add some of the applications URLs and try it out * if you want to have a finer grained security policy where certain users can access certain resources, then set up a policy on the opensso server. the sample application shows how to do this. Try to set up a simple policy for the simpleapp.war and restrict certain users to certain pages * if you want to have a common access denied page showing when a user is not allowed access to some page (instead of just browser default page for 403 error), then set the property for com.sun.identity.agents.config.access.denied.uri = some page, and maybe add a page into the simpleapp.war. * if you have also set up the J2EE agent sample application, then it can also participate in SSO with the other 2 web apps. This way you can see an example of a web app using J2EE declarative security (web.xml security elements) and a simple web application(no security specifies in web.xml) can work together. Make sure you have the J2EE agent property com.sun.identity.agents.config.filter.mode = ALL so that the sample app can use its J2EE security to login to J2EE container security as well. |