I have installed OpenAM (OpenSSO) to work with my liferay portal. So authentication for liferay is going now through the openam server. This works fine.
But now I want to secure my own application (EAR) deployed on my glassfish application server.
I can not find any example how to configure my web module to work with openam/opensso.
Can anybody help me how to configure my web application?
The usual approach is to install an OpenAM Policy Agent onto your Glassfish server. The policy agent will intercept all requests to glassfish before allowing them to be processed by the application server, forcing the user to authenticate first if they need to.
Once your policy agent is installed, you will be able to configure it to do many things. Restricting access to some or all URLs in your applications is the most obvious use. Protected applications can also access user details (such as UID or givenName) provided by the policy agent through HTTP headers.
The Glassfish agent is a J2EE policy agent. See here for configuring a J2EE policy agent in OpenAM:
http://openam.forgerock.org/doc/admin-guide/OpenAM-Admin-Guide/chap-agents.html#configure-j2ee-policy-agent
See here for installing the policy agent into Glassfish:
http://openam.forgerock.org/doc/agent-install-guide/OpenAM-Agent-Install-Guide/chap-glassfish.html
Related
The SSO details of my application is configured on Azure side. I got metadata and Certificate. Now how to use this on the tomcat side. One of my web application is running on tomcat and this web application is protected using this SSO.
I have a Shibboleth service provider (SP) served by a web farm with no outbound internet access (for security reasons). The web farm forwards authentication requests to the shibboleth daemon running on a computer that does have outbound internet.
Because of this separation, I'd like to minimize the installation on each box in the web farm. I have the following questions:
Is it possible to xcopy-deploy Shibboleth to the web farm, rather than using the installer? If so, what are the minimum files in addition to the isapi_shib.dll?
If using the installer on each server in the web farm is necessary, what folders/files can be removed post-installation? (For instance, I see I can disable the "Shibboleth 2 Daemon" service...)
And by-the-way I am using using http://www.testshib.org for integration testing.
I'm running IIS 7.0 on a Windows 2008 R1 Server and want to setup IIS Manager Users. Due to some fact, every last try to access the site is rejected (HTTP Unauthorized).
The following additional IIS components are installed:
Security\Basic Authentification
Security\URL Authorisation
Management Tools\IIS Management Console
Management Tools\Management Service
Then I configured the Management Service to use Windows or IIS-Manager-User Credentials.
I also added some IIS-Manager-Users and activated them on my Website.
On the Authentification Settings Pane, I disabled anonymous access and enabled basic authentification.
As a result, when browsing the website, a password is now required. The thing is, I can access the page with Windows Credentials, but not with the IIS Manager User Credentials. In this case the result is always HTTP 401 - Unauthorized.
What am I missing?
IIS Manager Users are meant for administration of IIS (aka management of the sites/apps) and not for access the server at runtime (normal browsing of content).
Having said that, you can make that work if your scenario is to use the same users for potentially administration (like using WMSVC) and runtime and I wrote a blog about it on 2008 on how to set it up:
http://blogs.msdn.com/b/carlosag/archive/2008/09/26/using-iis-manager-users-in-your-application.aspx
I am developing a windows service application that will run on customer PC/servers and access a Web API endpoint hosted in an Azure Website. It needs to authenticate the user, and I would prefer not storing credentials on the customer's machine. So, I've landed on client certificates to authenticate the users. I have this working against a local, non-Azure Website IIS instance with self-signed certificates. However, I'm unable to get it working in an Azure Website.
As far as I can tell, there are two issues that I'm not finding much documentation on:
How do I install my own CA certificate in the Trusted Root of the Website instance(s)? Or will this only work with CA certificates that are already trusted?
How do I enable "Accept Client Certificates" for this application? In IIS you do this under "SSL Settings". Documentation indicates that modifying the system.webServer/security/access node of app.config will accomplish this, but obviously you can't do that in Websites. Documentation for websites suggests this node is unlocked for use in web.config, however adding that node results in an error "The page cannot be displayed because an internal server error has occurred.", even if custom errors is off.
For Azure web sites vs web roles client authentication options are rather limited. Websites don't let you run programs with elevated permissions, which is required for making IIS changes and storing certificates into the trusted root.
There's a way to configure you website to always (you don't get the benefit of making it optional as with IIS 'Accept' configuration) request client certificate. This feature is currently only available through Azure management REST API, you can't access it through the portal UI. You can find more information here.
Essentially you turn on clientCertEnabled website setting to true. The mechanics of this option are different from traditional client authentication where server needs to have a CA certificate with which the client cert is signed in its trusted root. The server doesn't run any validation on the client certificate, the application needs to run the cert check itself, which comes in a request header "X-ARR-ClientCert". GetClientCertificate() extension method on HttpRequestMessage will parse it automatically.
Alternatively, you can host your Web API as a web role. That gives access to running startup tasks with elevated permissions that allows access to trusted root and making IIS configurations, more details/examples here. You can either copy the CA certificate to the app folder or upload to the user store via Azure portal so that it is available for copying over to the trusted root in a startup task. IIS changes can be made via “Microsoft.Web.Administration” library available as NuGet package through ServerManager class.
For question 2, here's a blog post on how to install client certificates on Azure Websites: http://azure.microsoft.com/blog/2014/10/27/using-certificates-in-azure-websites-applications/
For question 1, you can't install your own CA certs as trusted root certificates, but if you have certs from a CA that's already trusted then you can use them without any issues.
I have a GWT webapp running on tomcat 7 on RedHat. All clients reside within intranet and use IE7 from XP machines to access the webapp.
The new requirement is to setup per user log. If user claims he did something wrong because of webapp, the admin should be able to check webapp responses for that request. Another requirement(a very nice to have feature) is to avoid login/password screen and use domain username instead.
I think I can ask my admin to setup Integrated Windows Authentication for Tomcat http://www.tomcatexpert.com/blog/2011/06/22/windows-authentication-apache-tomcat. Once IWA is implemented on Tomcat I expect I will be able to access username with HTTPServletRequest.getRemoteUser() from my webapp.
Am I right in my assumption?
Is there a simpler way than that?
The integration of a Java container such as Tomcat with a Windows Domain through IWA, SPNEGO, Kerberos etc. can be a very complicated task and the Tomcat instructions that you point to may or may not work the first time and may also require changes to the way your Windows environment is configured.
Once that integration is working, your web application will need to specify auth constraints in web.xml to protect part or whole of the webapp. Although it may not prompt for user id if the Windows authentication set up is working seamlessly, it is necessary for the configuration to be there before getRemoteUser will return anything inside your application.