Is there any utility that can be used to generate LTPA token keys for the WebSphere Liberty Profile. I am aware of the Liberty generating token by itself whenever we start the liberty server.
Also I have found a utility which helps one to generate LTPA for Domino based. But it doesn't work for WebSphere as we don't have a server secret.
My requirement is to generate the keys externally. Any help here is appreciated.
Liberty automatically generates LTPA key and stores to ${server.output.dir}/resources/security/ltpa.keys. See more details here - Configuring LTPA in Liberty.
So if you want to generate your own just configure your own password in server.xml, like this:
<ltpa keysFileName="yourLTPAKeysFileName.keys" keysPassword="keysPassword" expiration="120" />
and it will generate keys using your password.
There is no standalone external tool. You can just use separate version of Liberty to create it and than share wherever you need.
Related
Background: my web-app is running in PROD, and real users are using it. The initial authentication was implemented using Spring Basic Security.
Recently, client decided to use SSO for authentication, so my app should act as SP with client IdP. I used Spring SAML to configure my app as SP.
Integration with client IdP on QA environment involved next steps:
Get and store IdP metadata file received from customer.
Deploy code with SP configuration on the environment.
Generate SP metadata file using /saml/metadata endpoint and share it with customer.
Get a green light from customer IdP side that SP metadata file in a right place.
Verify that SSO is working successfully.
Now, It's time to deploy SP SSO configuration on PROD environment and integrate it with client PROD IdP.
I don't like to use the approach above for PROD, as real users will not be able to login into the app until app SP metadata file will be generated, and put in a right place at customer IdP.
Can anyone tell me how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD?
(1) Quote "Recently, client decided to use SSO for authentication, so my app should act as SP with client IdP. I used Spring SAML to configure my app as SP."
Response:
I suppose that you use Spring SAML provided by the official GitHub repository of Spring Security SAML to "configure your app as SP".
(2) Quote "Integration with client IdP on QA environment involved next steps:.."
Response:
The five (5) steps (provided by your post) regarding integration of your web app as SP with client IdP are the practical SAML standard for "deploying SP SSO configuration on PROD environment and integrate it with client PROD IdP."
I have shared hands-on experience on integration of web app as SAML SP with SAML IdP by providing my answer to another recent Stackoverflow question "I have provided an instruction to address another Stackoverflow How can I generate metadata file of my Java Spring Application to establish a connection with Identity Provider like Ping Federate?"
(3) Quote "I don't like to use the approach above for PROD, as real users will not be able to login into the app until app SP metadata file will be generated, and put in a right place at customer IdP."
Response:
If you "don't like to use the approach above for PROD", you can modify the source code of "spring-security-saml/samples/boot/simple-service-provider/" (provided by the official GitHub repository of Spring Security SAML) to configure your web app as SAML SP.
(4) Question "Can anyone tell me how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD?"
Answer:
(I) The README on "How to run a simple sample of an Identity Provider (IDP) and Service Provider (SP)" (provided by the official GitHub repository of Spring Security SAML) will guide you "how can I generate SP metadata file for my app in advance, before deploying SSO configuration on PROD".
(II) I highlight the related information on "how to generate SAML SP metadata file of Spring Basic Security for my web app in advance, before deploying SSO configuration on PROD" (Quote your question).
Step 2 - Start the Service Provider
Service Provider runs on http://localhost:8080/sample-sp
$git clone https://github.com/spring-projects/spring-security-saml
$cd spring-security-saml
$./gradlew :spring-security-saml-samples/boot/simple-service-provider:bootRun &
(II.a) Launch a web browser to access the URL http://localhost:8080/sample-sp
to ensure that Spring Security SAML Service Provider runs well.
(II.b) Launch a web browser to access the SP metadata endpoint
http://localhost:8080/sample-sp/saml/sp/metadata
to download or "generate SP metadata file for my app in advance, before deploying SSO configuration on PROD" (Quote your question).
(5) Question "Spring SAML: alternative ways to generate SP metadata besides using /saml/metadata endpoint"
Answer:
you can modify the source code of "spring-security-saml/samples/boot/simple-service-provider/src/main/java/sample/config/SecurityConfiguration.java" (provided by the official GitHub repository of Spring Security SAML) to "generate SP metadata besides using /saml/sp/metadata endpoint".
For example, if you want to generate SP metadata from a specific endpoint such as /example/metadata, then you just need to replace
"super("/saml/sp/", beanConfig);"
(in the source code shown below) with
"super("/example/", beanConfig);"
public SamlSecurity(BeanConfig beanConfig, #Qualifier("appConfig") AppConfig appConfig) {
super("/saml/sp/", beanConfig);
this.appConfig = appConfig;
}
As long as you know the URIs of the endpoints and the signature certificate you can generate them manually and specify it in the configuration.
we am trying to use vault to keep database credentials and using token in by spring boot application to fetch secrets. Credentials are kept at secret back-end at vault. Connection with application and vault is secure to TLS. This kind of secret distribution is still vulnerable and depends on the developers maturity. Once application has the access to secrets it can be logged in the files. Unlike traditional JEE application, data source is looked up in resource jndi and application never now the database credential. resource setup was done by operations team and access to credentials were limited. Application never has the credential visibility.
Is my understanding correct, if that so how we can make secrets more secure in spring boot application or is this the trade off we have to compromise with.
Very Good Question.
As I think secrets can be logged in the files. As we are getting from vault.
We have to compromise on this. Its same as any secure information (eg. customer data) regarding application can also be logged in the files.
It should be taken care by developer and reviewer.
We are trying to configure a Liberty Server to host and render custom JSR286 portlets to IBM Portal via WSRP. The Default Server configuration for features and LDAP, LTPA and SSO is done and two IBM WSRP 2.0 Producer EAR files have been deployed. One is configured for NO security and the other have been configured for WS-Security by setting the Environment Variables in the web.xml files respectively.
On the portal server we can get the portlets consumed from the non-secured producer, and have configured HTTP LTPA cookie forwarding for the secured producer.
When trying to consume a portlet from the secured producer, I can see the LTPA cookie in die SOAP headers, but we are getting "MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood"
I followed the WSRP Documentation on how to configure security for WSRP for Websphere Liberty by using HTTP-cookie-based sso : See section "Securing the WSRP Producer by HTTP-cookie-based single sign-on" in WSRP Documentation
Following this info, I still get the "MustUnderstand headers: [{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security] are not understood" error in the logs.
All I need at the end of the day, is a secure way to use the WSRP producer (Downloaded from IBM WSRP 2.0 Producer) on Liberty profile to expose portlets to IBM WebSphere Portal and exchange the user context for the portlets to be able to get the logged in user details.
How do one configure security for WSRP for WebSphere Liberty?
NOTE: Not Full profile, but for Liberty profile.
Can somebody please help or point us in the right direction
have you done the steps to share the ltpa keys and set both consumer and producer to the same user registry
The doc states this "The requirements for SSO depend on the authentication method that is used. For example, if you use LTPA version 1 or version 2, the WSRP Consumer and the WSRP Producer must use the same user registry or use the same realm. In addition, the WSRP Producer and the WSRP Consumer must exchange shared keys that are used to sign the security credentials."
per here https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/wsrpt_prod_sec_ws.html
I would test that SSO is working by itself before trying to even bring wsrp into the mix
and more steps to configure on the consumer https://www.ibm.com/support/knowledgecenter/en/SSYJ99_8.5.0/admin-system/wsrpt_cons_sec_ws_http_cb_sso.html
I am using WebSphere v8.5 and in the administration console, and the Security Settings in the Data Sources section allow me to set my mapping-configuration alias to either ClientContainer or WSLogin. What is the difference between these two settings?
I am able to connect and my project appears to work regardless of which setting I choose. Can someone please explain when is one setting chosen over the other?
Each one in the list is a Java Authentication and Authorization Service (JAAS) configuration, which in turn contains an IBM-implementation of the JAAS Login Module.
According to the reference page, Login configuration for Java Authentication and Authorization Service:
The WSLogin module defines a login configuration and the LoginModule implementation that can be used by applications in general.
The ClientContainer module defines a login configuration and the LoginModule implementation that is similar to the WSLogin module, but enforces the requirements of the WebSphere Application Server client container.
The DefaultPrincipalMapping module defines a special LoginModule that is typically used by Java 2 Connector to map an authenticated WebSphere Application Server user identity to a set of user authentication data (user ID and password) for the specified back-end enterprise information system (EIS).
So for general use, you can use the WSLogin module. When you use a Java EE client, use the ClientContainer module. And when using Java 2 Connectors, use the DefaultPrincipalMapping module.
Check this link for a bit more information Configuration entry settings for Java Authentication and Authorization Service
In general, for any server resources like Datasources, queue connection factories etc, you should use DefaultPrincipalMapping.
ClientContainer alias is more dedicated to external applications running in the client container that will connect to WAS, and WSLogin is more appropriate for apps running on the server that would like to customize authentication process.
In my web application, need to use the siteminder implement the SSO with websphere liberty profile. But how to configure the liberty profile and siteminder and let them work smoothly? Hope your tips. Thanks.
WebSphere Liberty profile supports the Trust Association Interceptor (TAI) plug-point (similar to the full profile WebSphere) that a SiteMinder provided TAI implementation can be used to integrate with for SSO.
You can search for SiteMinder and WebSphere to get more information about their TAI implementation and integration with full profile. Configuration of TAI in the liberty profile is described here