Rapid IdP FAQ’s
What do I need to do to set up a new Identity Provider?
Watch the video demonstrating the process of creating a new IdP, adding a user, and signing into federation service with the user. The final product will look different to this, but the general workflow will be similar.
Will the service allow bilateral Service Provider connections?
We’re intending to have some basic support for direct / bilateral agreements with individual service providers, though the simplest option is to encourage service providers to join the federation where possible. Through the Early Adopter Program we’ll develop a better understanding of the extent and variety of bilateral agreements we need to support.
Will there be a limit on the number of bilateral Service Provider connections in the SaaS IdP?
There hasn’t been a decision made on this yet, but there will likely be a limit. We will use the Early Adopter Program to find out more about existing bilateral agreements and work with participants to establish reasonable operating parameters for the final product.
How configurable will the attribute resolver be?
When the hosted IdP is using LDAP for authentication / attribute resolution, the attribute resolver will be fully customisable.
Will the service allow the connection of databases hosted at my organisation? Or will we need to host them in the Amazon cloud?
We’ll have full support for authentication / attribute resolution from an external directory via LDAP. Any additional databases which the SaaS IdP uses will be hosted in the Amazon cloud and managed as an integrated part of the IdP.
Do you offer a VPN connection between our infrastructure and the SaaS IdP?
There is no VPN support for a connection between the IdP and your organisation’s infrastructure. Though we can’t offer VPN support, other organisations have set up a firewall rule to only allow traffic from three static IP addresses (owned by AAF) over a specific port. The hosted IdP will only accept LDAPS (TCP 636) or LDAP+StartTLS (TCP 389) configurations.
We don’t allow access to our LDAP directory outside of our network. This is fine for an on-premise IdP, but how will it work for a SaaS service?
Organisations normally implement networking security to block access to directories from outside the organisation. This configuration can be changed but obviously carries an increased risk for the organisation.
We understand there are security risks associated with providing access to a corporate directory via LDAP to the outside world. This risk can be mitigated with the following measures:
LDAP will only operate over a secured transport such as TLS. This is mandatory – the SaaS IdP will not accept an LDAP configuration using an insecure transport.
Restrict permissions for the LDAP credentials. We recommended that the LDAP credentials given to the SaaS IdP only have access to the attributes required for AAF purposes. The account should only have rights to read (not update) data.
Use point-to-point firewall rules to restrict connectivity to the corporate directory. We’ll provide a list of IP addresses so that access can be restricted to your SaaS IdP servers, rather than operating a public directory server.
You will not need to set up a public LDAP store, but you will need to modify your firewall rules to allow communication between your existing LDAP directory and your hosted IdP instance.
Do you support SPNEGO/Kerberos for single sign-on from Windows desktops?
There are several technical challenges to providing SPENGO/Kerberos support in the Hosted IdP. AAF would need to register each IdP node in the customer’s LDAP directory. This happens on initial creation and any time nodes are destroyed and recreated. The system architecture means this could happen regularly as new features are released — nodes are designed to be disposable appliances. We’re not comfortable with privileged access to your LDAP directory and don’t expect that your security team will be either.