Opening SSH to AWS-hosted Linux servers via mRemoteNG

mRemoteNGmRemoteNG is nice and lightweight tabbed session manager. It is a perfect fit to manage your remote server farm with both Windows and Linux machines, since it supports multiple connection protocols out of the box – including SSH and RDP (yet, you may need to update your older Windows client to run newer RDP version).

However, connecting to Linux instances that run on AWS requires a bit more than just SSH client. As you probably know, Linux EC2 instances have password authentication disabled by default to prevent brute-force attacks and want you to supply your private key instead. But there is no such field in mRemoteNG configuration pane! So, how can you configure it to send your private key instead of password?

It appears that mRemoteNG relies on embedded PuTTY to provide SSH support. In turn, PuTTY by itself is able to work with private keys authentication required by AWS. Here is the detailed explanation about the configuration steps.

Continue reading “Opening SSH to AWS-hosted Linux servers via mRemoteNG”

SimpleSAMLphp – my favorite SAML 2.0 software package

After struggling some time with CAS, I finally ended up working with SimpleSAMLphp package. I can recommend it as really simple yet powerful software. The package contains ready-to-use SAML 2.0 IdP site and provides PHP API to integrate your application with SAML 2.0 Service Provider functionality. The handling of the actual authentication process is delegated to a rich set of authentication modules, and in case no build-in module fits your needs – you have all the power to implement your own module in hours.

Why you should not use CAS 3.5.1 as SAML 2.0 Identity Provider

[ Update (June 2014): Please take some time to check John’s comment below. ]

Last week I spent some time investigating SAML 2.0 support of Central Authentication Service 3.5.1 (latest version of CAS at the moment of writing). The results were disappointing.

CAS was developed by Yale University in early 2000’s and was donated to open source in 2004. It is primary used in the academic networks, but the use is now extended to the enterprise world. Initial versions of CAS were built around own custom interoperability protocol. Later it was extended to support more protocols – both standard (such as SAML 1.1, OAuth, OpenID) and custom (REST API).

The skeleton for SAML 2.0 support was implemented around 2003. The implementation was driven by the need to integrate CAS with Google Apps for Education even before SAML 2.0 was finalized as a standard in 2005. As you may guess, this implementation is not fully compatible with the approved standard. Unfortunately, it did not change a lot during those ten years. The relevant documentation page says “SAML 2.0”, yet mentions the fact that it is actually intended for Google Accounts in the big red warning at the top. The supporting code is more conscious and presents itself as “GoogleAccountsService”.

But even if you don’t really care about spec compatibility, SAML 2.0 implementation of CAS is extremely limited and is not fully secure.

First, CAS implementation does not support SAML 2.0 metadata. Besides the inconvenience of manual configuration on SP side, it has serious implications on the IdP itself. CAS will not maintain the list of trusted SPs – it will be glad to work with any SP, including  malicious ones, and will not verify validity of signed authentication requests. Actually, the whole request content besides the request ID (which must be returned in the resulting assertion) and “AssertionConsumerServiceURL” attibute (see below) is simply ignored.

As another implication of missing metadata notion, CAS will not have the pre-configured return URL for each SP and will rely on “AssertionConsumerServiceURL” request attribute. This attribute is defined as optional in SAML 2.0 specification, and some SP implementations do not provide it. Obviously, CAS will fail (in the ugly way – with NullPointerException) if this attribute is missing and will not be able to continue the flow if it does not contain valid URL. And if all this is not enough, just think about invalidated redirects

The content of the resulting response is also far from being perfect. It is built from a fixed template, with only few values replaced. Among hard-coded values are assertion issuer (sic!), authentication method and some dates. Even the computed values are mostly not configurable – for example, the assertion is always valid for 1 year. Authentication attributes that are required by some service providers are not supported also.

Bottom line:
If you are looking for enterprise-grade software to be your SAML 2.0 Identity Provider, CAS 3.5.1 is not for you.

How to configure multiple EAIs with different authentication levels in WebSEAL

A week ago I had to investigate whether it is possible to configure multiple EAIs in WebSEAL, when each one provides different authentication level. While configuration of several EAIs is pretty simple – all that you need is one trigger URL per EAI, and this is perfectly supported – placing each one of the on the own authentication level does not look trivial. The definition of authentication level per authentication method in WebSEAL is implicit, by the order of the authentication methods in the list.

For example, the list below defines password authentication to be level 1 and EAI to be level 2:

[authentication-levels]
level = unauthenticated
level = password
level = ext-auth-interface

But how do you define EAI to act as both first and second method? Well, simple – but not so intuitive:

[authentication-levels]
level = unauthenticated
level = ext-auth-interface
level = ext-auth-interface

Note that here EAI is mentioned twice – both as a first and as a second authentication level!

Additional missing piece of the puzzle is to tell WebSEAL which one of your EAIs represents each authentication level. This is solved via special “am-eai-auth-level” HTTP header from your EAI back to WebSEAL upon successful authentication, in the same way you send the username:

HTTP/1.1 200 OK
Date: Thu, 28 Jun 2012 12:00:00 GMT
am-eai-user-id: john
am-eai-auth-level: 2
Content-Type: text/plain
Content-Length: ........

Now you have to check with EAI should be invoked when the user comes to the login page. This information is available to your login page via %AUTHNLEVEL% macro. The processing can be easily done via JavaScript on the static logic or using server-side processing when LRR is enabled.

Unauthenticated Access to WebSEAL Junctions

[ Update (April 2013): How to perform this task with ‘pdadmin’ utility. ]

By default WebSEAL junctions do not require any specific authentication for external access – they just derive the default ACL definition of the WebSEAL. However, this default ACL does not allow access to unauthenticated users. So, efficiently the users have to pass authentication with any available authentication method to gain access rights for the junction that does not need any specific authentication.

Here I will explain how to define unauthenticated junction – a junction that allows access to any user, including users that did not pass WebSEAL authentication at all. In fact, creating unauthenticated junction in WebSEAL is super-easy and super-simple when you are experienced WebSEAL professional. If you are a newbie or WebSEAL administration is not among your main tasks, the logic of this flow is not so trivial to guess (or even recall).  Continue reading “Unauthenticated Access to WebSEAL Junctions”