This content has been marked as final. Show 3 replies
I understand its a bit confusing. I apologize for that. We have tried to document the nuances in that link you provided.
An empty <login-config/> makes all you pages public. The document link that you pointed out has this information -- here is what it says:
+"Public application. An application that completely requires public access without an SSO challenge must just include an empty <login-config/> element in web.xml."+
If you want your pages to be secured, you not only have to put <login-config/> but also provide <auth-method/> underneath it. Absence of <auth-method> makes the pages anonymous.
For e.g. to make all you pages secured with SSO you have to add this:
Other methods supported are BASIC and FORM.
You can pick and chose which portion of you web page to be protected by providing the <security-constraint>. Also explained in that same link.
Also, remember that you must set the <cookie-path> to a unique value if you have 2 or more apps deployed that requires authentication.
I hope this help.
Thanks. That clears up the public-ness of some web apps. (Not sure why if a web app has NO <login-config> tag at all that the cloud requires a log in, but I'll leave that for more pressing issues below.)
I am still having trouble with my web app with protected resources, though. I have defined users and the "boss" role and assigned some users to the "boss" role by using the Identity Console. But the problem is that users are NOT required to log in when they access the web app! Since they don't log in, of course the role-based security does not work, since we don't know WHO they are when they request a protected resource.
Here is the relevant part of web.xml:
What am I doing wrong?
Sorry for the delayed response ,
Let me answer your first question "(Not sure why if a web app has NO <login-config> tag at all that the cloud requires a log in "
The reason behind this is as Oracle Public Cloud is a "Enterprise" Cloud offering we have secured by default security posture.
This is to protect our customers so they don't expose applications to "public" internet unintentionally.
Explicit requirement of login-config element addition enforces this security constrain.
Regarding your web.xml and the weblogic.xml ,
web.xml look fine to me, I suspect the weblogic.xml configuration may be an issue
If the role "boss" is created under service "java" (or whatever is your service instance name ) then you should try following in the weblogic.xml
<principal-name>trialabgx.java.boss</principal-name> #(or trialabgx.<Your Service Instance Name>.boss )