April 29, 2020 at 4:02 pm #27857
I am embarking a journey of implementing SSO in web applications. These applications are running different versions of Jboss 5.x, 6.x and 7.x and tomcat, webservers and the approach for integration is SAML. The application is the service provider and OPen AM is the identity provider. Open AM authenticates the user against LDAP and let’s the application to load their home page. I am looking for a solution to address the following
a) In the event of forgerock OpenAM going down, is there a way to redirect to the login page(in SAML) as a fall back, so that application user can use the traditional login page to get into the application
b) i have 2 types of users – standard users already part of LDAP AND non-standard users to do the admin or maintenance activities which are not registered in LDAP. How do i support both users using SAML. Should i need to have separate URL for the application to support the admin users to login using their credentials. Is there any better design which can be followed.
c) for SAML integration, considering there are different versions of web & app server is there any common service which can leveraged by the application and reused centrally for Sso integrationApril 30, 2020 at 8:19 pm #27870
There’s some ambiguity in your questions – so it will require some follow-up. But below are my 2 cents:
a. Does your SP need to support more than one Identity Provider (IDP)? If yes, you may want to look into IDP discovery service which works by using
Common Domain Cookie. AM’s implementation of discovery service is based on this implementation or
4.3of the SAML core spec.
If above is not the case and your login page refers to the one being served by the application (SP) itself, you could likely simply ask the user how they want to login (discussed in the SAML discovery spec) or this page keeps track of AM state through “isAlive” URL. If AM is down, it presents user with a login page and so on.
b. where is your non-standard users hosted? are they not in the ldap? AM will need to know where these users are (via identity stores) for them to be able to login. E.g. you can create a separate container for admin users (and separate groups) within your ldap and control authorization via Policies.
c. i am not too sure of your question. SAML implementation is done at the application layer. And these applications can continue to run on diff version of web/or app servers. but if your application doesn’t support SAML and you are looking for a SAML plugin (kinda) on the SP side for SAML SSO – then you need to look into
Identity Gateway (IG). Look at the docs for more info on this.
Hope this helps!May 1, 2020 at 3:34 pm #27881
Jatinder, Thanks for your reply
a. The login page is within the application(SP) for the users to login. How to check the status of AM from the application when the URL is invoked from application(SP) when the application is integrated with AM using SAML as an option. What if the AM returns up and running and by the time the application SSO is invoked AM goes down. How can i handle this from the application, since the applications are critical and cant wait for AM to be up. Is there a fall back implementation or any reference doc which can be shared
b. The application has to maintain non-standard users for maintenance of users. They are yet to be on-boarded to LDAP and this migration could take a while to complete. In essence, when standard users can use SSO , there should be a login page to manage the non standard users who has to login to the application without SSO. How can this be designed so that end user experience(for standard and non-standard) is transparent when application gets migrated to SSO
c. While SAML2.0 is supportive of the different app/web servers, each application need to develop separate program to interface with OpenAM using SAML for getting the users authenticated. I am looking for an optimum effort to have a common plugin or a web service which can be invoked/reused by all application (SP) to save time and speed to deliveryMay 4, 2020 at 7:10 pm #27885
If the applications that AM is protecting are mission critical, IMHO AM implicitly becomes a mission critical component of your architecture as well. So it may make sense in your scenario to look into High-Availability (HA) and Fail-Over implementations and architecture.
The non-standard users if I understand correctly are admin users maintaining the site. Now, I don’t know what you are using but I can give you an example of something similar. Liferay for example provides a way to create multiple sites which can be set-up and controlled from the administration portal. Within Liferay an admin can configure a SAML2 connector for a given site such that all users of that site go through SAML2 SSO. But the administration portal in this case is managed by Liferay’s built-in user management. So both user groups log-in differently i.e. site users via SAML2 SSO and Liferay admin users via built-in user management. This is a design implemented by Liferay. If your app doesn’t support this out of the box, you will need to implement this yourself. One option is via AM’s authorization policies – but the prerequisite for this design is your users need to be within AM’s reach via LDAP. Once implemented – your app can serve admin pages for admin users and non-admin pages for standard users.
Your question in (c) seem to be similar to my above thoughts. You are essentially looking for a plugin/adapter that can basically connect your application (SP) with AM (IDP). Your best option is to look into
Identity Gatewayas suggested above.
Hope this helps!May 5, 2020 at 7:05 pm #27889
Thanks. I went through the docs on identity gateway. Understand this is for connecting enterprise apps that are legacy and want to implement SSO with openam
Are there any security threats using identity gateway or fedlets as compared to sp initiated saml integration with open am. While this is costly and time consuming to develop saml capabilities in the application , need to choose scalable and secure option to integrate with openamMay 6, 2020 at 3:44 am #27892
These are production ready products but you will have to do your due diligence and go through the hardening exercise. IMO – deploying a Fedlet may be a lighter option in your scenario than a full blown IG. I suggest to go through the Fedlet documentation for more details.
P.S IG also utilizes Fedlets to implement SP driven SAML2 SSO.May 7, 2020 at 9:52 am #27895
Thanks. Is there any guideline document on using Fedlet for any application with a demo. I am planning to do due diligence for an inhouse application. What are the pre-requisite to be installed ? can i use trial version of AM to proceedMay 7, 2020 at 3:50 pm #27898
I suggest the following docs from backstage:May 8, 2020 at 10:03 am #27899
thanks for the docs. Regarding non standard admin users , based on your comment below
One option is via AM’s authorization policies – but the prerequisite for this design is your users need to be within AM’s reach via LDAP. Once implemented – your app can serve admin pages for admin users and non-admin pages for standard users.
If the admin users are not in LDAP, how the application can serve admin pages when integrating with OpenAM. These users will continue to be supported with a login page and standard users will be SSO without login. can this be designed in OpenAM for admin user. Else this will be cumbersome to maintain landing page of the application with link for SSO and form for non SSO users. Is there any recommendation based on yoru experience
You must be logged in to reply to this topic.