I am wondering whether J2C authentication in Websphere corresponds to Java2 Security or J2EE security.
What is the difference between these two?
While configuring J2C Authentication alias in WAS Console, are we configuring Java2 Security or J2EE Securiy?
I am prety much confused in these. Please help me in this regard.
Thanks.
Java2 Security and J2EE Security:
Java 2 Security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. Java 2 Security is independent of J2EE role-based authorization. Java 2 Security guards access to system resources such as file input and output, sockets, and properties, whereas J2EE security guards access to Web resources such as servlets and JSP files. WebSphere global security includes J2EE role-based authorization, the CSIv2 authentication protocol, and SSL configuration. Java 2 Security can be disabled and enabled independently of WebSphere global security (the Enforce Java 2 Security check box in the Global Security Panel or Server Level Security Panel). However, when WebSphere global security is enabled, by default Java 2 Security is also enabled. Note that Java 2 security can be disabled even though WebSphere Global Security may be enabled.
You can read more about it from here.
J2C authentication
J2C Authentication uses a Java Authentication and Authorization Service (JAAS) pluggable
authentication mechanism to use a pre-configured JAAS login configuration, and LoginModule to map a
client security identity and credentials on the running thread to a pre-configured user ID and password. WebSphere provides container-managed sign-on functionality. The application server
locates the proper authentication data for the target Enterprise Information System (EIS) to enable the client to establish a connection.
Application code does not have to provide a user ID and password in the getConnection call when it is
configured to use container-managed sign-on, and authentication data does not have to be common to all
references to a resource.
Related
In ActiveMQ Artemis when I use the requisite or required flag with my custom JAAS login module I am not able to login to the Artemis management console (Jolokia, port 8163). I have special business logic in the custom JAAS login module which authenticates mobile devices. But at the same time I want to have an admin user who can login to Artemis management console with some username/password or even without password. In order to have both custom and guest login module in Artemis login.config, I have to keep the security flag of custom JAAS module as sufficient at-least. How can I handle this situation?
The security "realm" used by Hawtio is configured via the hawtio.realm system property set in etc/artemis.profile. For example, here is the default:
JAVA_ARGS=" -XX:+PrintClassHistogram -XX:+UseG1GC -Xms512M -Xmx2G -Dhawtio.realm=activemq -Dhawtio.offline=true -Dhawtio.role=amq -Dhawtio.rolePrincipalClasses=org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal -Djolokia.policyLocation=${ARTEMIS_INSTANCE_ETC_URI}jolokia-access.xml -Djon.id=amq"
Here the hawtio.realm is set to activemq which matches the entry in the default login.config, e.g.:
activemq {
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule sufficient
debug=false
reload=true
org.apache.activemq.jaas.properties.user="artemis-users.properties"
org.apache.activemq.jaas.properties.role="artemis-roles.properties";
org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule sufficient
debug=false
org.apache.activemq.jaas.guest.user="myUser"
org.apache.activemq.jaas.guest.role="amq";
};
I don't see any reason why you couldn't add a new realm/domain specifically for Hawtio to your login.config and then change the configuration in artemis.profile to reference that. That way you can customize security for Hawtio connections and messaging connections however you wish.
Also, it's worth noting that Artemis recently added support for per-acceptor security domains. You can read more about this in the documentation.
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
Specifically, running a chain of postfix, dovecot and nginx to provide a "nice" mail service to (not so many) users. All services share Pluggable authentication module (PAM) as a possible authentication method. Currently, the system's "passwd" database is being used to auth again via PAM.
AWS Identity and Access Management (IAM) is a hard requirement. Therefore, any other service (like duosecurity) is not an option. Before I start to code a PAM module, I'm asking for your experience - how would you do it? Thanks!
This might not be what you are looking for, but certainly qualifies as a way to use IAM as a authentication “method” for PAM:
Denis Mikhalkin's (denismo) aws-iam-ldap-bridge periodically populates the LDAP directory location with the users, groups and roles from AWS IAM, which will in turn allow to use libpam-ldap or libpam-ldapd and thereby implicitly authentication of the Linux users against AWS IAM using their AWS IAM Secret Keys as passwords.
Please note the following rather significant caveats:
At the moment, the plugin requires a custom version of ApacheDS so manual configuration is unlikely - see Configuring an existing ApacheDS LDAP server
The default configuration is INSECURE however you are free to alter it to your requirements - see Security notes
Personal Assessment
While a native IAM PAM integration would be great (and also enable advanced use cases like AWS Multi-Factor Authentication (MFA)), I like the pragmatic approach to just facilitate the widely used LDAP integration instead - still I would definitely prefer a solution that ideally works with any compliant LDAP server, or at least with a stock ApacheDS distribution, in order to ease installation, maintainability and security assessments.
I didnt find anything according this issue.
Can jaas be used to secure my rest service? When yes, are there any advantages compared to basic/digest auth + ssl? Should I use jaas over basic/digest auth for my rest service?
Yes you can use JAAS to secure a REST (or any other type of) service.... as long as your REST container provides the ability to hook JAAS Login Modules.
Most containers I know, do, Tomcat and Jetty in particular.
JAAS is no so much about how the credentials are formatted or made available (Form Login, Basic auth, etc...) but more about how you validate them. You may want to check a local file, query an DB or an LDAP server...
JAAS is not only authentication, but authorization too. Once you have passed the authentication phase, the roles and permissions you provide to the user. All containers that implement JAAS will provide a seamless integration between the JAAS module and the authorization scheme provided by the container such as the one provided by web.xml for servlets.
Since JAAS is a standard and is now part of the JRE, you will find a lot of ready-made modules and documentation on the web to help you build your own if need be.
Are there any open source centralized authorization services available? There are lots of solutions for centralizing the authentication information (eg: CAS and JOSSO), but what about the authorization information?
There are some really good authorization frameworks (eg: Spring Security (formerly Acegi) and Seam Security), but it seems that I have to composite these into individual tiers or services. In other words, I can't run them standalone very easily. With a SOA, it seems like it would be very valuable to centralize not just the authentication but the authorization information as well (ie: roles, permissions, rules, etc.).
Any suggestions?
Are you looking for something that supports XACML? If so, the closest to open source you can get is the OpenSSO project which has portions of what you seek.
The openly available Kerberos implementations provide Client Service Authorization as well as Client Authentication.
Read about Using Kerberos 5 on Red Hat Linux.
Hum, maybe you can use a SSO solution and create a service which returns all the authorization information (roles, permissions, rules, etc) and make each application use this service to get each authenticated user authorization information.