Can someone please explain the major differences between IBM Tivoli Access Manager and Tivoli Federated Identity Manager?
Does TAM support SAML?
Updated Answer: SAML is now supported with ISAM v9.
The names and versions of the products have been updated/changed. Basically, TFIM and TAM are now old names and products. All of the functionality and code of TFIM has been rolled into to ISAM v9. ISAM v9 now has Web, AAC, and Federation components. (ISAM v8 did not have the Federation componentm ISAM 8 only had Web and Mobile)
ISAM 9 Web - reverse proxy that handles authentication/authorization to back-end web servers
ISAM 9 AAC (Advanced Access Control) - more advanced authorization functions tailored toward mobile devices like device fingerprinting, geolocation awareness, and IP reputation
ISAM 9 Federation - all the old TFIM code with updates
old Tivoli Access Manager (TAM) -> new IBM Security Access Manager (ISAM)
old Tivoli Federated Identity Manager -> new ISAM v9 Federation
I will elaborate a bit more since nzpcmad 's answer fails to address TFIM at all.
IBM Tivoli Access Manager ( now IBM Security Access Manager) handles the authentication and authorization part of your IAM infastructure.
IBM Tivoli Federated Identity Manager allows for federated and web Single Sign On. It can be used with ISAM, for example in a scenario that ISAM delegates the authentication part to TFIM for certain resources/cases.
ISAM does not speak SAML by itself, but it can leverage TFIM that does.
Other than that, you would have to ask something more specific in order to get concrete answers.
In general, an Identity Manager provisions users into an identity repository e.g. AD / LDAP. It also provides password self-service etc. The provisioning includes user attributes and roles.
An Access Manager provides authentication (using the identity repository) and authorization based on the users attributes, roles and credentials provisioned by the Identity Manager.
Related
I am using WSO2 Identity Server 5.7.0 and WSO2 API Manager 2.6.0. We want to use the user management and role & permissions management of WSO2 itself, but the as per requirement we cannot use WSO2 carbon management GUI for user creattion, role mapping etc.
We need to have a separate GUI but integrate with WSO2 User, Role and Permission management.
For this purpose, WSO2 must have some kind of APIs exposed for third party application integration?
For example, I have checked user creation, user update etc operations are having corresponding SCIM REST APIs which can be used by our applications.
Is there similar APIs for :
1) Creating Service providers
2) Creating permissions at service provider level
3) Creating role mapping at service provider level
4) Creating roles
5) Associating permissions with roles
6) Associating Users with Roles.
Please let me know details of such REST APIs provided by WSO2 if any.
Am searching for Desktop application manage Enterprise
Single Sign On
(SAML v2, Identity Provider , Service Provider )
Here is how i achieved in my enterprise:
There could be 2 approaches
Use "windows authentication" which can give you actual user trying to access website. Any enterprise application ( assuming it being hosted on Intranet) has integration to Active Directory. This User identity can be authenticated using LDAP server
Use OAuth way and use Third party which provide Identity management. Front End calls their services to generate token. This token can be sent to backend which will authenticate this token against the validator service.
I have used ADFS 2.0 as RSTS for SSO where in we have all the IdentityProviders and the Relying parties are configured. You can use the active end point of the STS (in case you want to authenticate against external sources like web api/ web service/ AD/ Database then prefer writing you own custom STS as the IDP).
Firstly you will get the boot strap token from the IDP and then get the Relying party token from the RSTS. In both the calls you need to communicate against the active end point (a wcf end point which implements WS Trust protocol).
Passive end points/ passive calls are used for thin clients.
You can try using ADFS 3.0 which even supports JOT (JSON) tokens (a very light weight token) along with SAML 2.0.
We have identity server V3 used inside my web application. We would like to use same identities to communicate with sharepoint 2016. Any repository or doc available on how to implement single sign on for sharepoint 2016 and Identity server V3 ?
You'd have to research how to get sharepoint to use IdentityServer as its identity provider.
I prototyped SSO in a test SharePoint 2010 environment a few years and used the links below for assistance. Some of the information may be outdated but I think the relationship between the STS (which in this case would be Identity Server V3 - Thinktecture) and SharePoint has not changed.
I am currently setting up SSO with our SharePoint application as well as other applications. I am using Azure Access Control Service (ACS) to act as a repository for all of the Identity Providers we would like to use. The providers are Facebook,Google,Windows Live ID and LinkedIn. ACS allows you to add custom Identity Providers as well. We have a CRM application that we currently authenticate against within our SharePoint application using claims and forms based authentication. This will be a custom identity provider defined in ACS. I am beginning to work with Thinktecture to be the identity provider that will sit on top of our CRM application. Users will then be able to login to SharePoint with any of the identity providers specified in ACS. We will see how it goes but I believe this will work. I would start with the General HowTos to using STS in SharePoint link.
FederationMetaData.xml editing
http://stsmetadataeditor.codeplex.com/documentation
http://social.msdn.microsoft.com/Forums/is/Geneva/thread/c0791595-2e0d-48cb-82f0-8e0f0bc1809a
http://jefferytay.wordpress.com/2012/05/03/windows-identity-foundationupdating-an-expired-issuer-certificate/
Regarding the "The issuer of the token is not a trusted issuer" error message.
search string - sharepoint 2010 The issuer of the token is not a trusted issuer
http://social.msdn.microsoft.com/Forums/en-ZA/sharepoint2010general/thread/f7dbbf1b-f616-4b24-ae0c-e8c76aa300d5
FedUtil.exe Information
http://msdn.microsoft.com/en-us/library/ee517284.aspx
General HowTos to using STS in SharePoint
http://msdn.microsoft.com/en-us/library/ff955607.aspx
I have an ADFS single sign on application. Can we also have form authentication using login credential from a database on the same application? In other words, I need single-sign-on for people who have windows account and form authentication for people who do not have windows account. I did some research on this topic but I have no lead. Is there any suggestion?
Out of the box ADFS can only authenticate against Active Directory (The latest version of ADFS (vNext) do supports LDAP v3-compliant directories).
You need to build your own Custom Authentication Provider for ADFS if you would like to plugin your custom code.
Some pointers for further reading:
Understanding WIF 4.5
Create a Custom Authentication Provider for Active Directory Federation Services
According to the documentation it only seems possible to authenticate against the windows azure service management API by attaching a certificate to each request which I previously have uploaded to the management portal.
The new management API has been built using the service management API, but it uses windows live authentication. Is it possible to use windows live to get the windows azure subscription ID and the certificate, so I can use the same authentication mechanism the management portal uses?
What makes you think that the Service Management API uses Live ID for authentication? It is just the portal that uses Live ID for authentication.
If you dig a bit you will notice that all the service requests from the management portal are made against https://manage.windowsazure.com/Service while The Base URI for management service is: https://management.core.windows.net
So, No, you can't authenticate against the Management API with Live ID. Moreover, it is the Management API is not new. The portal is New. The management API has been there for a while and is updated from time to time to reflect new services that are coming.
UPDATE AFTER THE 2 COMMENTS
Following Gaurav's explanation I will just add a simple architecture diagram (super simplified and totally my thought, but this is how would I build it in very minimalistic way):
[User's browser (portal)] ==> Sends XmlHttpRequest (AJAX) to ==> [Portal Service]
then
[Portal service backend] ==> signs request with predefined certificate and sends request to ==> [management.core.windows.net/subscription-id/whatever/service/command]
This actually is a very common practice to provide UI to a (web) service.
This way both conditions are implemented:
You use Live ID to authenticate with the portal
The Windows Azure Service Management API are yet, still and only protected by a Certificate.