Project Background:
I am setting up a small farm where the Intranet is its own application. Following the Least Priveleged Account setup principle, I have Domain User accounts created for each process/app. pool. The service authentication works great over Kerberos.
One of the projects needs to have another web application (separate from the Intranet) exposed to clients through the Internet. In order to keep the AD structure separate, we decided to go with ADAM. The app. pool account is separate and also uses Kerberos. Following https://blogs.pointbridge.com/Blogs/morse_matt/Pages/Post.aspx?_ID=2, I extended my original application and configured it as an Extranet zone assigning an LDAPMembership provider as outlined in the article.
The dilema
While the people picker works and allowes me to specify Collection Administrators, Site Owners, Members, etc. from both AD and ADAM data stores, I am not able to log my users in. I constantly get the user could not be authenticated error. And nicely enough, the LOG produces no errors related to Directory lookups. It seems that the ADAM data store is never hit.
My own idea, based on MS articles, is that because I do not use NTLM, the crawler never gets to the Extranet zone. Yet, how should I go about securing the application if we all know that Kerberos is superior to NTLM.
Any ideas would be very much appreciated.
Note: SPNs were properly set up, permissions were assigned as required, the ADAM users have disabled set to false, app. pool accounts are listed in the Readers role container inside ADAM
Thanks,
Jack
One thing that you could check is the opening of network ports. I am assuming that your web server and LDAP server are on different network segments.
Idea is that LDAP port and SSL port are different. If the people picker uses the LDAP port and the login uses the SSL port, then this could explain why one works and the other does not, and why the calls are not reaching the LDAP server.
Related
My goal
overall goal
I want to serve various applications running on docker containers hosted on the same server, each on a subdomain of company.com. And I want only people from my organization (Microsoft AD azure) to access subdomains, in some cases even only people having specific AD groups.
goal specific to Keycloak
I simply want to have specific realm roles have access to specific subdomains, and nothing else. And this, using only a single realm client (see further for explanation).
what I have achieved to do
I have linked several applications on a server and serving each using traefik on a specific subdomain. For example app1.company.com and app2.company.com.
I have also made a middleware so that all routers using it will make sure users must login. I have used a thomseddon/traefik-forward-auth container that I called oauth. I am using Keycloak and I have successfully linked an Azure Active Directory as identity provider. For this, I enabled a single-tenant application and used its client id & key. I also mapped successfully some AD group to a Keycloak role.
Within oauth configuration, I have added the client id & secret from a single keycloak client rather than from the azure application. I believe this is mandatory if we want to use traefik to redirect trafic.
Now, only people from within my organization can access each app. Success!
Some documentations I used
Homelab Single Sign-On & TLS
How to Configure Microsoft Azure Active Directory as Keycloak Identity Provider to Enable Single Sign-On
what I want to do
Each application has its own subdomain. However I cannot figure out where to make it so that some subdomains are accessible only if a user has a specific realm role (linked automatically depending on a AD group thanks to the above-mentioned mapper).
I thought of adding resources within the Keycloak client, but I don't find how to do it using subdomains.
other alternative is to make one client per subdomain, but this means I need to run one oauth container per subdomain... This seems overkill & a waste of resources without counting maintenance.
The only relatively simple solution I found was to create one Keycloak client per type of permission rules (aka Roles in Keycloak) I wanted.
Then for each type, I had to make a traefik-forward-auth container and connect it to each Keycloak client. I am still using the same Identity provider, so once you've configured it to generate roles, you only need to tell which roles may use which client.
To give an example, you want to have 3 types of permission rules: one for admin, one for trusted users, and one for untrusted user. It could look like this:
admin.example.com
trustedusers.example.com/app1 and trustedusers.example.com/app2
untrustedusers.example.com/app3 and untrustedusers.example.com/app4
You would then have 3 forwardAuth middlewares within traefik.
It is a little bit more cumbersome, but your applications are still connected to your OIDC provider using a single key, then you manage the details using keycloak and these clients.
Of course there is still the solution to have one client per application as is originally planned. This may be unnecessary, and cumbursome if you have a large number of applications (one additional container per application + additional middleware).
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
I'm working on the web app which will be hosted on the client's server.
There are various restrictions/security measures in place and I'm concerned that these can be "hacked" because the client will have a direct access to the ASP.Net user database through the SSMS.
I can think of few ways to stop the user from doing this, but I'm interested to find out whether there are any specific standards that I should follow?
If the client has direct administrative access to the database, there's not much you can do. If these are the client's login details - why is this then a problem?
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).
Is it possible to access a sharepoint web service without authenication? If you can't do it directley can you think of any ways to get round it such as haveing an open service inbetween that does authenicate for you using a public account.
John,
The security model of the web application through which you're trying to access the web service in question is going to drive whether or not you can access the service anonymously. If you're attempting to access the web service through a web application on which anonymous access is enabled, then you'll be able to hit the web service. Go ahead and try this on an anonymous site (if you have one): http://yoursitehere/_vti_bin/lists.asmx. You'll get the friendly service page back, no auth required.
Here's the catch: once you traverse the web service layer, you've got another layer of security to deal with. SharePoint itself is going to want to check permissions for access via the web services just as it normally would, so unless you are attempting an operation or trying to access data that is allowed for anonymous users, you're going to get blocked.
You have a handful of options:
Simply ensure that everything you're trying to do is permitted anonymously. This may sound easy, but it can actually be pretty difficult for anything but the simplest and straightforward of operations. Most organizations, too, don't care for opening things up to this extent.
If you control the code that's calling the web service, then you have the ability to attach credentials to the web service request. I recommend starting here, as it is going to make things a lot easier than trying to throw everything wide open. Plenty of examples exist on attaching credentials to a web service proxy (e.g., http://msdn.microsoft.com/en-us/security/cc178918.aspx)
Finally, you could write your own web service that wraps the SharePoint web service (or services) of interest. You could permit anonymous access to your web service and then adopt an appropriate security context within your own service to access SharePoint with the required permissions level.
I hope this helps!
Sean
I don't think you can, most actions the webservices perform need an explicit user with the correct permissions set. If both sites are internal, your options might include
Using automatic NTLM authentication, give the complete Authenticated Users group the necessary acecss. Using IE or the proper extensions to FireFox credentials will be automatically passed without user prompting. Your mileage may vary.
Passing the proper credentials to a default user explicitly in the call to the webservice
from that other website.
If you feel creative, here is a blog from Reza Alirezaei where he walks through the steps of mapping the anonymous user onto a specific account. If you manage to give that acount the proper permissions, you are there. Not for the faint of heart, though.