We have a websphere commerce application running on WAS 7. After enabling global security and application security,on accessing the application url , the browser prompts for login...only after logging in using the server admin credentials,the request is served..is this the expected behaviour of enabling security??
Yes, this is expected behavior. After enabling global and application security, access to application is enforced, if it has security configured in deployment descriptor.
Regarding admin credentials - you are probably using default file registry, with single admin user. You can change who is authorized to access application in the application details page, clicking Map user for security roles. You can specify users, groups, or special subjects like all authenticated and everyone- which would allow to access your app without login, if you really want that.
Related
I have the following access policy configured that should blocks access to Microsoft Teams, if there is no valid client certificate:
This policy works in the browser, when teams.microsoft.com is opened (including logging in with valid crendetials) with the custom error message:
Yet, while using the Teams Desktop App, the affected user can login and use teams even without the certificate. The message in the Activity Log of Microsoft Cloud App Security states "bypass session control".
How does the rule not affect the Teams App but work in the browser.
The teams app cannot have access to a certificate, because I tried it in a Sandbox.
As well as the bypass info must mean, somewhere a bypass is allowed/configured? But where would I find that?
If you extend the policy to also check the Client App both for Browser and App, then also the Teams App will be blocked by the policy (or not if the certificate is available).
• You are able to access Teams client app on desktop because you have not selected filters that include ‘client app equals to Mobile and Desktop’ in Access Control Policy as below.
• So, once you select the filters as per your convenience, as above, and the actions to take as ‘block’ or ‘test’, the desktop teams will not be able to start up. Also, the ‘bypass session control’ message in the browser while accessing a blocked or restricted site is displayed in activity logs in Microsoft cloud app security because you might be having ‘admin’ level access to modify, create or delete any access control or session control policy in there.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/cloud-app-security/manage-admins
https://learn.microsoft.com/en-us/cloud-app-security/troubleshooting-proxy
I was trying to register an Application Login Module in Websphere but I don´t find any easy example in web.
There are a lot of IBM documents, but too much complex, and I can´t figure out how to register an Application Login Module.
I already have success with a System Login Module bounded to WEB_INBOUND, it works, but affects all my system. I want a Login Module to serve only my applications web, with JAAS authentication.
I´ve tried to bound a login module to existing WSLogin but it doesn´t seems to be working.
Any help ?
tks[]
You need to setup security domains to get the separation you are looking for wrt to the login configurations. The security framework uses the WEB_INBOUND login configuration to authenticate the user for all web applications irrespective of adminConsole or user applications. When you create a security domain and customize the WEB_INBOUND configuration at the server/cluster domain level, it will be used for all the user web applications deployed in those processes. You need to setup the multidomain in a cell topology and assign the domain to the server/cluster where you applications are deployed.
Once you setup the domains, the WEB_INBOUND configuration at the server/cluster domain will be used by the user applications hosted in that server/cluster while the WEB_INBOUND configuration at the admin/global domain will be used for the adminConsole application at the Deploymener Management process where it is deployed.
The application JAAS login configurations are meant to be used by the applications directly. One can create an application login configuration and programmatically use it in the application to perform direct login -
LoginContext lc = new LoginContext("myAppLoginCfg1", callBackHandler);
I asked around and this is the answer that comes from the owner of container security:
The WEB_INBOUND is a JAAS system login that is always configured by default. However, you can specify your own JAAS application login or customize the existing WEB_INBOUND system login. If you want only one application to use a different JAAS login from all your other applications, you can use a security domain that has those different security configurations. The only catch is that application server has to be in a separate server from the other apps. That way, you can map your security domain to that server.
Here's an info center article about security domains:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/tsec_sec_domains_config.html?cp=SS7K4U_8.5.5%2F1-8-2-33-1
And one on application logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/rsec_logmod.html?cp=SS7K4U_8.5.5
And system logins:
http://www-01.ibm.com/support/knowledgecenter/#!/SS7K4U_8.5.5/com.ibm.websphere.zseries.doc/ae/usec_sysjaas.html
And here is a much more practical answer that comes from the security dev lead:
So an additional question is - why would you want to do that? Do you want to do anything specific for just one app during login that you do not want for other app logins? (I would think so) You can get the app name in your custom login module and can use that to provide your own app based login requirement in your login module (or skip it) if needed.
Me: Ya, this is what I would do. You can also implement this based on what is in the request. I did one where it would request a SAML token from an STS and put it on the runas subject if I could tell that the request came from WebSeal (and not if it didn't).
If what you need to do for the 'app-specific' case requires skipping what is done in ltpaLoginModule and wsMapDefaultInboundLoginModule (that should run for the other apps), you can't really do that. However, you can modify their behavior.
Read through the task I've given a link to below. Yes, I understand it is a WS-Security task, but its about using APIs. You'll get what I'm talking about if you read closely, particularly the 3rd ("When a caller...") and 5th ("To use a..") paragraphs. The parts that you should be concerned about in the code is the WSCREDENTIAL* stuff.
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_config_wssec_caller_no_reg.html
So I have a application that I want to check if a user is in a AD-Group to be able to access.
I checked out passport-kerberos but I could not see how to detect the user's add groups without logging the user in, which he already is on the domain.
On C# .Net solutions we use on IIS this runs just fine, but how can I get this on Node.js with Linux as server not microsoft?
Google isn't being very friendly in terms of this are so I'll just ask the question here instead...
Just wondering are there any disadvantages or perils that I should be aware should I decide to enable Anonymous access on IIS 6 or 7 for a web app that runs internally? (i.e. never exposed to the Internet)
Thanks.
One disadvantage to anonymous access in an intranet is that it prevents you from having any control over user access for the web app.
For example, by using windows authentication, you can allow authenticated users access to your web app, thereby forcing users to be authenticated inside your domain. This is an extra security measure for intranet, and the usual implementation for an intranet web application in an enterprise environment.
It will be hard to audit access using IIS logs, as it will always be the anonymous identity used. This may impact any enterprise auditing requirements that may be in place. Again using windows authentication can allow all domain users to access the web app, while providing accurate auditing and access log information.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).