WAS Liberty - How to trigger JAAS module? - jaas

Using WAS 8558 and on one of the URL pattern, need to invoke JAAS module.
Entry in web.xml
<security-constraint>
<display-name>SampleConstraint</display-name>
<web-resource-collection>
<web-resource-name>Sample</web-resource-name>
<url-pattern>/wasauth</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>
Users allowed access to spoke Identity Provider</description>
<role-name>FIMAnyAuthenticated</role-name>
<role-name>FIMUserSelfCareAnyAuthenticated</role-name>
</auth-constraint>
Entry in server.xml
<jaasLoginContextEntry id="system.FIM_OUTBOUND" name="system.FIM_OUTBOUND" loginModuleRef="myCustom, hashtable, userNameAndPassword, certificate, token"/>
<jaasLoginModule id="myCustom" className="com.*.SampleLoginModule" controlFlag="REQUIRED" libraryRef="customLoginLib">
</jaasLoginModule>
<library id="customLoginLib" apiTypeVisibility="spec, ibm-api, api">
<fileset dir="/" includes="com.**_8.0.0.jar"/>
This flow is using Federated repository feature (Liberty) for authentication.
Above mentioned settings allow user to get authenticated against repository however JAAS module is not getting invoked.
If I convert JAAS entry to system.WEB_INBOUND using WSLoginModuleProxy - JAAS module gets invoked.
Liberty does have appSecurity-2.0 feature enabled.
Is there any other configuration which needs to be done?

When the Liberty profile performs authentication for protected web resources it uses the system.WEB_INBOUND JAAS login configuration entry. So any custom login modules that you have configured in it will be called.
If you have configured your custom login modules in your own or a different JAAS configuration it will not be called by the server during web authentication. Your application. however, can call it directly.

Related

MobileFirst 8.0 using user credential in database for mobile client login?

I know the users can be configured in server.xml like this way :
<!-- The users defined here are members of group "appcentergroup", thus have role "appcenteradmin", and can therefore perform administrative tasks through the Application Center Console. -->
<user name="appcenteradmin" password="admin"/>
<user name="demo" password="demo"/>
<group name="appcentergroup">
<member name="appcenteradmin"/>
<member name="demo"/>
</group>
But if there is thoundsand of users, how to configure mobileFirst using the user credential in database to login mobile client (IBMAppcenter)?
The default configuration added by IBM Application Center is to read a limited set of users from basic file based registry. The pre-defined roles are mapped to these users.
When you have thousands of users, it is most likely in a LDAP. In this scenario, you should configure your application server with this LDAP and have Application center validate the users against the LDAP. Role mappings are associated such that after the user validates successfully against the LDAP, it is assigned the appropriate role.
More details here:
Configuring LDAP with Liberty
Configuring LDAP ACL management
AppCenter LDAP JNDI parameters

sso saml with weblogic and openam

I'm trying to setup saml sso with openam and weblogic.
The reason why I want to use saml is that I have multiple application where I can't change the web.xml to use the j2ee agent.
My question is if there is a good document explaining the setup with weblogic and openam.
I have read several guides, but I'm still confused...
Just looking for a good howto!
My current setup is
openam on tomcat installed on host1
weblogic installed on host2.
Webapp deployed on host2
So openam will be the IdP and weblogic will be the SP? right?
I have configured the openam hosted IdP.
I have added the saml identity asserter on weblogic and configured a web sso identity provider partner.
You can configure WebLogic to enable SAML SSO implementation. This requires the following steps to be completed.
WebLogic and IDP(OpeanAM) should be coupled - you can register OpeanAM as an authentication service provider inside WebLogic container using the administration console.
This requires a SSL communication, hence ideally, it's better to install a SSL certificate inside the container.
WebLogic can be configured to implement SAML SP (Identity asserter and Assertion consumer) by configuring the required through the administration console.
In fact it can be configured to work as a Credential mapper and Assertion receiver on the same way.
All these steps can be done inside a single WebLogic instance or between instances using a WebLogic federation.
Please refer the below link for more details.
I don't think WebLogic itself can act as SAML SP. Every application has to implement an SAML SP. Doing this via Spring Security SAML extension is quite neat. If you want more efforts look at the OpenAM Fedlet (it's also a lightweight SP). However the sample app generated when creating the Fedlet is not too helpful. The 'Fedlet' is not the sample all ,but more or less the jars and metadata included in the sample app.

Worklight Console protection using LDAP

I'm able to protect Worklight console with an user inside worklight.properties file (on Liberty or WAS environment).
How can I protect console with a LDAP user (outside of the worklight.properties file)?
Yes, you can do this.
You will need to edit your authenticationConfig.xml as follows:
Add a LDAP loginModule
Add a LDAP realm
Update the existing "WorklightConsole" custom securityTest to use the new realm
After the above changes, once loading Worklight Console and entering the user credentials,
these should be handled by the loginModule to authenticate against the LDAP server.
See the following IBM Worklight Getting Started training module, which is about this very topic:
Using LDAP Login Module to authenticate users with LDAP server

Using #RunAs between a servlet and an EJB

I have the following servlet.
#DeclareRoles("remote-guest")
#RunAs("remote-guest")
public class GuestServlet extends HttpServlet {
#EJB
private Test test;
#Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
test.guest();
}
}
The servlet is mapped such that only users with role guest can call it.
<servlet>
<servlet-name>guest-servlet</servlet-name>
<servlet-class>test.web.GuestServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>guest-servlet</servlet-name>
<url-pattern>/guest</url-pattern>
</servlet-mapping>
<security-role>
<role-name>guest</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>guest-resources</web-resource-name>
<url-pattern>/guest</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>guest</role-name>
</auth-constraint>
</security-constraint>
The Test EJB is implemented by the following TestBean class.
#Stateless
#DeclareRoles("remote-guest")
public class TestBean implements Test {
#RolesAllowed("remote-guest")
public void guest() {
System.out.println("TestBean.guest()");
}
}
Problem: when I call the GuestServlet using a user that is mapped only to the guest role, the EJB throws an javax.ejb.EJBAccessException despite of the presence of the #RunAs annotation on the servlet. Should I also map the user to the remote-guest role? If the user has to be mapped both to guest and remote-guest, what's the real purpose of #RunAs?
Yes, a user needs to be mapped to the role. Although it might be a different user from the one that has the "guest" role. As stated in the EJB 3.1 specification 17.3.4.1:
Because the Bean Provider and Application Assembler do not, in
general, know the security environment of the operational
environment, the run-as identity is designated by a logical role-name,
which corresponds to one of the security roles defined by the Bean
Provider or Application Assembler in the metadata annotations or
deployment descriptor.
The Deployer then assigns a security principal defined in the
operational environment to be used as the principal for the run-as
identity. The security principal assigned by the Deployer should be a
principal that has been assigned to the security role specified by
RunAs annotation or by the role-name element of the run-as deployment
descriptor element.
And oracle jee6 tutorial:
http://docs.oracle.com/cd/E19226-01/820-7627/bnbyr/index.html
The role of #RunAs is to allow communication between 2 containers with different sets of roles and users (as in the link above) or to provide security identity for components that don't have security contexts: for example a Message Driven Bean needs to call another bean that requires the caller to have some roles.

Websphere 7 Portal: Servlet checking for login status to Portal?

I run a WebSphere 7.0 Portal. One has to log in to be able to see any information which is fine for all portlets. But additionally there are a couple of servlets that a deploy in the same war file that produce some raw data for AJAX-scripts.
Currently one can bypass the authentication from WebSphere Portal if one knows the URL to that particular servlet. I want to change this and check if the user is currently logged in to the Portal. How do I do this? I tried ((PumaHome) new InitialContext().lookup(new CompositeName(PumaHome.JNDI_NAME))).getProfile().getCurrentUser(); but this returns null.
WebSphere Application Server returns principal and remote user only if you configure it to use the JavaEE security context for your web application. Edit your web.xml to contain something like
<security-constraint>
<display-name>userConstraint</display-name>
<web-resource-collection>
<web-resource-name>secure</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>user</description>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>secrole</description>
<role-name>user</role-name>
</security-role>
and redeploy your application. After deploying your application take a look at the application's settings in the Administrative Console. You will notice "User/role mapping". Add "all authenticated users from trusted realms" to the newly added role. Restart the application.
After that anonymous users can not access your application anymore. Also, the getRemoteUser and other APIs will return the user properly.