We are migrating our application code from WAS 8.0 to Liberty 17.0.0.1. Our application uses mail functionality which gets invoked when user process a request. Could anyone help us in configuring mail in server.xml. Whether it is mandatory to provide user and password for tag in server.xml ?
I just did this myself. The XML requires you to provide those attributes, but if your server(s) don't require authentication, you can leave them blank.
e.g. here's mine (with server values changed, of course), where I currently only need to send outgoing mail via SMTP, which is the default for the optional transportProtocol attribute:
<mailSession description="My mail server" from="" host="mymailserver.com"
id="myMail" jndiName="mail/myMail" mailSessionID="myMailSession"
password="" user=""/>
If you are configuring the mail session in the server.xml then the userid and password are required. You have the option of encoding the password with the securityUtility (https://www.ibm.com/support/knowledgecenter/en/SSRTLW_9.0.1/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_command_securityutil.html) provided with Liberty.
Related
We currently have ADFS 2.0 with hotfix 2 rollup installed and working properly as an identity provider for several external relying parties using SAML authentication. This week we attempted to add a new relying party, however, when a client presents the authentication request from the new party, ADFS simply returns an error page with a reference number and does not prompt the client for credentials.
I checked the server ADFS 2.0 event log for the reference number, but it is not present (searching the correlation id column). I enabled the ADFS trace log, re-executed the authentication attempt and this message was presented:
Failed to process the Web request because the request is not valid. Cannot get protocol message from HTTP query. The following errors occurred when trying to parse incoming HTTP request:
Microsoft.IdentityServer.Protocols.Saml.HttpSamlMessageException: MSIS7015: This request does not contain the expected protocol message or incorrect protocol parameters were found according to the HTTP SAML protocol bindings.
at Microsoft.IdentityServer.Web.HttpSamlMessageFactory.CreateMessage(HttpContext httpContext)
at Microsoft.IdentityServer.Web.FederationPassiveContext.EnsureCurrent(HttpContext context)
As the message indicates that the request is not well formed, I went ahead and ran the request through xmlsectool and validated it against the SAML protocol XSD (http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd) and it came back clean:
C:\Users\ebennett\Desktop\xmlsectool-1.2.0>xmlsectool.bat --validateSchema --inFile metaauth_kld_request.xml --schemaDirectory . --verbose
INFO XmlSecTool - Reading XML document from file 'metaauth_kld_request.xml'
DEBUG XmlSecTool - Building DOM parser
DEBUG XmlSecTool - Parsing XML input stream
INFO XmlSecTool - XML document parsed and is well-formed.
DEBUG XmlSecTool - Building W3 XML Schema from file/directory 'C:\Users\ebennett\Desktop\xmlsectool-1.2.0\.'
DEBUG XmlSecTool - Schema validating XML document
INFO XmlSecTool - XML document is schema valid
So, I'm thinking that ADFS isn't playing full compliance with the SAML specification. To verify, I manually examined the submitted AuthnRequest, and discovered that our vendor is making use of the 'Extensions' element to embed their custom properties (which is valid, according to the SAML specification) (note: "ns33" below correctly namspaces "urn:oasis:names:tc:SAML:2.0:protocol" elsewhere in the request)
<ns33:Extensions>
<vendor_ns:fedId xmlns:vendor_ns="urn:vendor.name.here" name="fedId" value="http://idmfederation.vendorname.org"/>
</ns33:Extensions>
If I remove the previous element from the AuthnRequest and resubmit it to ADFS, everything goes swimmingly. And, in fact, I can leave the 'Extensions' container and simply edit out the vendor namespaced element, and ADFS succeeds.
Now, I guess I have 3 questions:
Why was the reference number not logged to the ADFS log? That really would have helped my early debugging efforts
Is it a known issue that ADFS's SAML handler cannot handle custom elements defined within the Extensions element, and if so, is there a way to add support (or at least not crash while handling it)? My vendor has offered to change the SAML AuthnRequest generated to omit that tag, but said that it 'may take some time'-- and we all know what that means...
Does anyone think that installing ADFS hotfix rollup 3 will address this situation? I didn't see anything in the doc to indicate the affirmative.
Thanks for your feedback.
When facing a MSIS7015 ADFS error, the best place to start would be enabling ADFS Tracing. Login to the ADFS server as admin and run the following command. If you have a very busy ADFS server, might be wise to do it when the server is not as busy.
C:\Windows\System32\> wevtutil sl “AD FS Tracing/Debug” /L:5
C:\Windows\System32\> eventvwr.msc
In Event Viewer select “Application and Services Logs”, right-click and select “View – Show Analytics and Debug Logs”
Go to AD FS Tracing – Debug, right-click and select “Enable Log” to start Trace Debugging.
Process your ADFS login / logout steps and when finished, go to the event viewer mmc find the sub tree AD FS Tracing – Debug, right-click and select “Disable Log” to stop Trace Debugging.
Look for EventID 49 - incoming AuthRequest - and verify values are not being sent with CAPs value. For example, in my case, it was I was receiving the following values: IsPassive='False', ForceAuthn='False'
In my case, to address the issue, all I needed to do was create incoming claim transformer rule - for the distinct endpoints.
Once the CAPs were transformed to lower case true and false, authentication started working.
Http Form adapter serves as an authentication service in my application. I have not implemented any application on the Identity Provider to get user inputs.
Therefore, on successful authentication, SP verifies the user's signature and redirects to the application. At my target Resource, I receive an open token. Is it still possible to utilize the open Token Jar to read the user attributes from OTK?
**Note: ** In Service Provider, I use open token Adapter.
Also, please let me know if there is any other possible way of getting the user attributes other than using the open token adapter/http form adapter.
Thanks.
There are numerous SP Adapters you can choose to use for your last mile integration with your application. The OpenToken Adapter is just one of them. If your application is in Java and you are using the SP OpenToken Adapter, then you would most likely use the Java OpenToken Agent implementation within your application to read the OTK (documented in the Java Integration Kit). If you look at the Add Ons list, there are actually 3 flavors of OTK Agents (.NET, Java and PHP from PingID. Ruby on Rails and Perl are available via respective Open Source repositories).
However, you are not limited to OpenToken Adapters. The Agentless Integration Kit is also very popular for SP/last-mile integration with PingFederate.
Unfortunately, the question is just too open ended for the Stackoverflow format. I would suggest talking to your Ping Identity Solution Architect who can help steer you in the right direction and ask the necessary follow-up questions on your use case.
If understand the question correctly, you desire attributes to be fulfilled that the web application can read and utilize. This starts with the SP Connection configuration. I am going to assume you are using Active Directory and already configured that data source along with the Password Credential Validator (PCV) for the HTML Form IdP Adapter. In the SP Connection you will need to extend the attribute contract to define the values to put into the SAML assertion and then use the Active Directory data source to fulfill the attributes. When the SAML assertion is received by the PingFederate SP role server, the SP Adapter maps the attribute values from the SAML assertion into the OpenToken. When your application receives the OpenToken, it can read the values.
We have a Plone 4.3 site on debian 7 that we'd like to authenticate against an existing AD controller. Using the excellent plone.app.ldap product we have this working, but the 'manager' username/password are being sent over the wire in plain text.
No doubt this is because we are using the protocol: 'LDAP' and not 'LDAP over SSL', our problem is how to implement 'LDAP over SSL' on the AD server in a way that works with Plone. Has anyone had any experience configuring the AD machine to accept these types of requests?
From what I understand it needs to be a new service on a new port, similar to https (i.e. not TLS), but I don't know enough about AD to know what to ask the AD admin mob.
EDIT: following the comment from #Martijn Pieters I add that if we set the 'manager dn usage' to not always then we get this error in the event log:
OPERATIONS_ERROR: {'info': '000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1', 'desc': 'Operations error'}
Thanks for any ideas.
-i
You could set up the LDAP connection to use a certificate instead of a password.
Ross Patterson outlines the procedure, but the mailinglist post he links to is gone. The same thread is however still available on GMane.
I followed the installation guide for an Apache Web Policy Agent, but it always results in an endless redirect loop between web and application server. Firefox says "The page isn't redirecting properly" and Chrome thinks that "This webpage has a redirect loop". The setup is an Apache 2 on port 80 with a small demo app and a Web Policy Agent, and a Tomcat 7 server on port 8080 with an OpenAM server (the former OpenSSO from Sun):
App URL http://hostname.example.com:80/ (App and Agent, running on Apache 2.2.16)
OpenAM Server URL http://hostname.example.com:8080/openam (running on Tomcat 7.0.12)
The Live HTTP Header Firefox plugin shows that the policy agent and the OpenAM server (i.e. the Apache and Tomcat servers) redirect to each other, although the server sets the SSO Token Cookie correctly. The name of the SSO Token Cookie has the default value "iPlanetDirectoryPro". Any idea how to solve the problem?
After a whole week I finally figured it out, with the help of Stackoverflow and the OpenAM Mailing list. There were two main problems: missing log files and missing cookie domains. Installing the OpenAM server and the Web Policy Agent is difficult, there are a lot of log files and many different configuration options. If you select the wrong options, it won't work. It is impossible to make it work without knowing what is going on, which can only be determined by a suitable log file.
Missing Log for Web Policy Agent : The log level must be set in the "Java properties" files. There are two "Java Properties" files for the Web Policy Agent, OpenSSOAgentBootstrap.properties and OpenSSOAgentConfiguration.properties. The log and debug level which is named com.sun.identity.agents.config.debug.level can and must be defined in both (!) files, and it should be set to the high level, all:4 or all:5. The format is important. Even if you do this, the AgentConfiguration.properties file is only used when the agent is not working in centralized config mode. The profile must be set to "local".
Missing Cookie Domain: Do not forget to enter the right Cookie Domain during the setup of the OpenAM server in the beginning, or add it afterwards if it is missing. On the OpenAM server, go to Configuration > System > Platform and change the Cookie Domain Value to your domain (for instace .example.com) if it is missing. Otherwise the browser will lose your cookie during the redirect process. Somehow I had an empty entry for the cookie domain at the OpenAM server, I guess a forgot a dot (example.com instead of .example.com) so that it was invalid (or something like that).
This troubleshooting site was helpful to locate the problem.
#0x4a6f4672, Your post was absolutely helpful . Some more to add to your answer. The following changes is what i had to do in the config to make it running, at-least getting it running it for alfresco.
com.sun.identity.agents.config.user.mapping.mode=USER_ID(Dont use HTTP_HEADER)
com.sun.identity.agents.config.user.attribute.name=uid
com.sun.identity.agents.config.user.principal=true(Dont use false)
com.sun.identity.agents.config.user.token=SsoUserHeader(Keep it as per what is specified in you application- in my case alfresco)
Now you are not running the Agent in centralised mode but in local mode the setting which is specified for profile attribute can be only set via property file so add the following.
com.sun.identity.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
com.sun.identity.agents.config.profile.attribute.mapping[uid]=SsoUserHeader(whatever you want the header to come in browser as)
As told by 0x4a6f4672, it is difficult to debug and unless you are in local mode , so switch to local mode immediately and start tracing the logs and make the property changes accordingly.
Is there any way to send an SMS through SQL Server 2008?
One possible option is to use an SMS gateway like the Clickatell API.
The Clickatell API offers a choice of connection options, including an SMTP method which you can use by sending a plain-text email from SQL Server to sms#messaging.clickatell.com, with the following body:
user: your_api_username
password: your_api_password
api_id: your_api_id
to: sms_number
text: sms_body
To send e-mails from SQL Server 2008, you might want to check out the following article:
Configure Database Mail – Send Email From SQL Database.
Another option is to write a CLR stored procedure that communicates with the SMS gateway through any protocol supported by the gateway.
Each phone carrier have email addresses that will forward to the sms/text of their subscribers and you just have send an email to these addresses and recipient will receive the messages thru sms.
example. 8009994141#phonecarrier.com
This is a link to a page to most of the carriers email to text format. Please note that this might contain not the latest information.
The best way is to call the technical support for your carrier get the information and test the feature by emailing and see if you get an sms message/
Yes, although not natively. You will have to use an SMS gateway service and do some programming around it. These come in several formats, occasionally free, but normally with some form of per message charge.
Standard gateways will accept message requests via email, a web post, or a full web service. Depending on the gateway service it may offer one, some, or all of these options.
Back in the "olden days" when I mobile SMS started to take off, in the UK at least, it was also possible to use a dial up modem to dial a network specific number and enter the SMS message. If this is still available in the area that you are looking for then the advantage of this is no account setup as it's charged to your phone bill.
I found an article which uses c# application with a SQL Server Backend to send SMS emails. Not exactly what your after but may give you another option.
SMS messages from SQL
How about an option that lets you do this in one line of code.
twiSQL - allows you to send text messages and make phone calls from SQL server
austinHenderson.com - author site
No, that is not a feature of SQL Server.
A simple way would be to write a CLR procedure that sends the sms via http to a SMS gateway of your choice
Just to add to nornal's answer since the link he spoke about seemes to have expired:
Alltel PhoneNumber#message.alltel.com
AT&T PhoneNumber#txt.att.net
Sprint PhoneNumber#messaging.sprintpcs.com
T-Mobile PhoneNumber#tmomail.net
US Cellular PhoneNumber#email.uscc.net
Verizon PhoneNumber#vtext.com
Virgin Mobile PhoneNumber#vmobl.com
So Ex: 3334441234#txt.att.net.
You use the above according to the provider.