Does GK portal (access to reporting, etc.) support SCIM (System for Cross-Domain Identity Management) for SSO federation?
https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management
https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/sync-scim
Customer question from Ally Financial
Related
We have in my organization an existing ASP.NET web application built in a SAAS model that our customers (users from different organizations) login through username/password authentication method. Users' credentials are hashed and stored in our database. We are currently working on adding a SSO feature to our application that would allow end-users from certain organizations to login with SSO using their own Identity Provider (Azure AD, Google, Okta, etc.) to perform the user authentication. We are using the OpenId Connect protocol to establish the SSO connection with IdP, and more specifically the Open Web Interface for .NET (OWIN) middleware. We have implemented the following:
Our SAAS application offers customers the ability to opt for SSO authentication through a setting. End-users from these organizations will be authenticating to our application via SSO AND using their own IdP
Our application supports SSO connection from different IdPs (Azure AD, Google, Okta, etc.)
Our application stores SSO connection settings for each customer that opt for SSO authentication (Client Id, Authority, Secret, etc.). All these settings are configurable in our application, they're available upon registration of the application on IdP side.
My question is about the app registration. I know that in order for our application to communicate with IdP and initiate SSO authentication it needs to be registered on related IdP, so that it can create a trust relationship. I am wondering which party should be responsible of the app registration:
My organization owner of the SAAS application? or
Our customers willing to use SSO authentication method?
With option 1, my organization will have to have an "account" on each of the IdPs our customers use for authentication (I feel this is not ideal for us), register our application and have a mechanism to invite our customers IdP to connect to the registered app.
I feel like option 2 would be the best approach for us as we won't have to deal with app registration, as customers will be responsible of registering the application on their own IdP. From my organization end we will just need to deal with SSO connection settings (Client Id, and other...) which will be provided to us by our customers upon app registration. I wanted to check if this is a common situation that some have already experienced, and what would be the best/recommended approach to go with. Thanks.
I am expecting app registration to be performed on customers side.
I would usually recommend that your internal services and APIs only need to trust tokens from one Identity Provider, and in your case you have one openid connect provider inhouse. That then supports your users to authenticate to and optionally authenticate using an external provider, like how the image below tries to show:
In my experience, having your applications trust and handle tokens from multiple sources will be a pain, as many of the external tokens might look slightly different.
I'm researching about CA Single Sign-On software (formerly CA SiteMinder®) and came across with two new definitions to me:
Web Access Management (WAM)
Identity Management (IdM)
On Wikipedia state these definitions:
IdM: "In computing, identity management (IdM) describes the management of individual principals, their authentication, authorization, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime and repetitive tasks."
WAM: "Web access management is a form of identity management that controls access to web resources, providing authentication management, policy-based authorizations, audit and reporting services (optional) and single sign-on convenience".
Despite of these two definitions seem to be clear, the more I read about them the more confused I am because I don't catch what tasks are exclusively of WAM and what of IdM. Where are boundaries? In what moment do they interact? Who is on charge of SSO? Both definitions talk about authorization and authentication and that confuses me.
I'm asking this because according to Liferay Wiki "Computer Associate’s (CA) SiteMinder is a centralized web access management system that enables user authentication and single sign-on, policy-based authorization, identity federation, and auditing of access to Web applications and portals."
If you reach "Architectural Use Cases: Simple Deployment" section (Implementation Guide -> Architectural Considerations) you'll see a diagram. If CA SiteMinder is a WAM: why does it do Authorization and Authentication? Do not are those tasks belong to an IdM? Is CA SSO also an Identity Access Manager? Then why does exist a product called CA Identity Manager?
Thanks.
PS: Feel free to correct any grammar or semantic mistake, I'm not English-Speaking ;-)
Identity Management (IDM) is concerned with the identity. Think of it as your digital wallet, as it contains all the information about you. This information can be used by other applications and is used by the Access Manager to control security. IDM does not manage security directly.
Access Manager (AM) can be some type of proxy system. For example, I currently use Novell, which leverages a reverse-proxy configuration. Access Manager is responsible for security and controls access to one or more resources for that authenticated user. In addition, it can provide SSL, Secure VPN, single sign-on services, SAML, and Federated support.
You normally need both component to build a complete Access Management System for an organization.
I am going to talk in terms of SAML but I'm not fussed about the protocols.
There will be a Federation Provider (FP) that trusts a number of external and 1 internal Identity Providers (IdP). The applications (SP) will in turn trust the FP. The SPs are a mixture of Java and .Net. The external IdPs won't know the permissions and claims to add to their security tokens for use by the SPs but the local IdP will. I need to associate the appropriate roles, permissions and groups to the identity so an SP can grant or deny access appropriately.
I can see 2 options:
The FP maps the external identities to local ones and does claims augmentation by querying the local IdP and enhancing the security token with the appropriate claims before passing to the SP.
The SP queries the local IdP and extracts the permissions that way.
What are the common patterns in this area?
Bonus points for suggesting products that support either of these scenarios (note: not a product recommendation which would be subjective, just a statement of capability)
Update: I have been impressed with the capabilities offered by Shibboleth SP, particularly the way it operates at the web server level freeing the application from the responsibility for handling SAML.
https://shibboleth.net/products/service-provider.html
We have built something similar to this, although our solution may not meet yours. Our model is a hub and spoke federation model where our hub maintains information about all users who have authenticated at least once in the federation. We provision the users on demand (ie: upon authentication) and allow augmentation of the users' data in the hub by administrators. We hide the very heterogeneous collection of authentication systems (SAML, CAS, LDAP, OpenID Connect) from the SPs that use the hub and normalize the claims that are passed to the SPs. In general, on the IDP side of the hub, the hub acts as a service provider; on the SP side of the hub, the hub acts as an identity provider. We've found that isolating the variability of the IDPs from the SPs is an effective abstraction for our SPs.
The architecture you describe is a common design pattern for a product (set of applications) hosted on the internet, where your users/partners have the option to provide an IdP or utilize your IdP for authentication. Many regulated industries require that Authorization be performed by the party providing the web applications and services. Since you will be doing authorization and adding attributes, you will need to manage all the user identities and have information provisioned for those users into your local database. Upon receipt of the authentication assertion, then it will be augmented with authorization information from your local database.
There are many on-premise Federation Solutions on the market today that perform the function you have described. I am going to focus on a SAML solution here, although there are other options for federation protocol. A couple of terms so the answer is more clear. The Identity Provider(s) will be the components that issue SAML assertions and only perform authentication, the Service Provider (SP) will be the component in your network to request/receive SAML assertions as well as augment the assertion with authorization data from your local database, and web applications to receive identity tokens, which are your applications.
Within the context of your network you will have a federation server that acts as the SP using the SAML protocol to all the desired IdPs. This component is essentially a federation hub. All of your web applications will communicate with this federation hub. An IdP Discovery service will be needed to determine where to route the SAML Request, which can be implemented within the federation hub, or in each application. My preference is to have the IdP Discovery as part of the federation hub. There are a couple of options for discovery such as using URLs or having a selection interface displayed to the user which is driven by the type of requirements and use case (workforce, business partner, customer). When your web application invokes the federation hub and associated IdP Discovery, then the SAML request will be sent to the appropriate IdP. Upon receipt of the SAML response, the assertion will be validated and subject retrieved. This is where some options come into play based on the vendor and business requirements you have for the solution. Products that act in the SP role as a federation hub that receive SAML assertions generally will have some type of plug-in interface or configuration that allows you to query for attributes from your local user database (or a directory service). Once all the data is combined, then a last mile integration occurs, either using SAML protocol, vendor protocol, or web service to the federation hub to get all the identity information. Since you have requested product that meets this use case, I have worked extensively with PingFederate by Ping Identity that will solve what you are looking to do.
I am a SP developing SAML 2.0 capability for SSO.
The SSO will ALWAYS be initiated from the IdP (Users will get to my site from their Enterprise Portal, where they are already signed in).
So, what I am trying to understand is whether I should just offer unsolicited (IdP initiated) SSO, or is it still best practice to develop solicited (SP initiated) SSO. If the latter, then why do I need the added complexity?
When, as you suggest, users will always be initiated from the IDP - and in fact every IDP that the SP is connected to - then there's no need to add SP initiated SSO support to your SP.
Of course one may argue that having support for SP initiated SSO is more generic and a superset of IDP initiated SSO because you would be able to trigger SSO from outside the IDP portal as well as include SP initiated SSO links in your Enterprise Portal. But in your case the former would never be required so you may stick with IDP initiated SSO only, assuming that all connected IDPs support that.
SP-initiated SSO is best practise in general, and OWASP states that "Unsolicited Response is inherently less secure by design due to the lack of CSRF protection."
We are considering to implement log on facility using SAML 2.0 on our portal. But is the use of SAML 2.0 increasing or should I use any alternative technology ?
From my organization's (Ping Identity) perspective, SAML 2.0 is still going very strong and likely won't be superseded anytime soon. There are plenty of SAML-based products available - more and more popping up every day. Major SaaS providers like Google and Salesforce have standardized on SAML 2.0 SSO, and we've seen over 1500 others do so as well.
There's some evidence to believe that OAuth 2 based SSO - or most likely OpenID Connect (built on top of OAuth 2) - will eventually become as predominant. At the moment it's mostly focused on consumer facing identity providers & applications like Facebook, Twitter, LinkedIn, etc.
SAML still reigns supreme in the business / enterprise world, where strong trust (federation) relationships are required.
Our school recently jumped on board the SAML 2.0 train. All of our students have access to Gmail for their school accounts. Now we are going to be using a cloud storage service for the students as well, employing SAML again for it. We are the Identity Providers (IdP) and our clients are Service Providers (SP).
I'm specifically using simplesamlphp for SSO generation, but that's merely my flavor preference. Java seems to be the other big platform SAML is used on. Either way, I don't foresee its use in the education industry going anywhere soon.