I have undertaken a project to setup Shibboleth that will allow for smart card authentication with our Netapp storage.
So far I have stood up a 2019 Windows Server. Placed Java JRE and configured JAVA_HOME variable. Tested the Shibboleth IDp installation to ensure it would run with the variable set. I also am waiting on a server certificate to be returned and I still need to create a service account for when I integrate the IDp with AD.
My question is, I've seen posts saying I need Shibboleth SP and IDp or I just need one or the other. Since we're just using this for smart card authentication, do I need both? The smart cards are already associated with the AD accounts. Big goal here is to have a prompt for the smart card when getting into the Netapp. Netapp is already pulling the accounts from AD but doesn't offer the smart card authentication.
Related
I am trying to setup SSO with third party IDPs in Google Workspace admin console.
I am using SAP IAS as an IDP.
It works with the default configuration.
But if i mark the the SAML requests to IDP must be signed in SAP IAS then it fails saying "SAML requests are not signed ".
It seems Google as a service provider does not sign the requests ? is it a correct understanding or is there a way to enable signing of SAML requests in Google workspace admin console ?
Best Regards,
Saurav
When you use Google Workspace as Service Provider with a third-party IdP requests are not signed by default and I am afraid that setting is not available in Google's side at the moment.
I assume by signing both the request and response of your SSO flow you are looking to grant extra security to this process however if you really need to use Google services and the authentication is successful without the setting I would recommend to skip this for now.
Neither in the documentation nor in the Google Admin console section for third-party IdPs SSO you would find it, the setting is simply not there:
Google as Service Provider setup
I hope this information helps!
I have an SPA web app using openidconnect for authentication and authorization with local keycloak.
This app is now moving to an windows onprem infrastructure using AD, kerberos tickets and a central SSO.
users log in in their windows session, and then we shall be able to transparently login in our SPA web app. (ie with out entering credentials)
How can I convert kerberos ticket/authentication into Openidconnect world? Where is the magic?
Shall we add some kerberos in our app?
how can we retrieve our access token containing the user role?
thanks
Your SPA should continue to talk to Keycloak using OIDC, and no code in the SPA should need to change. Your APIs will also continue to receive the same access tokens.
You should only need to configure Keycloak to use AD for authentication as an LDAP data source. Here is an article on how to do that. It is an infrastructure job rather than just a coding one, so I would recommend collaboration with AD administrators on the environment setup.
AD is only one possible authentication method, and by doing things this way you keep your options open. You are likely to need to perform account linking, eg to identify users the same before and after the migration. There may be some data setup involved here, eg ensure AD has the same emails as the existing system.
I'm trying to create a SAML IDP for the system I built. Probably I'm getting confused with concepts. My problem is as follows:
This system was built in SymfonyPHP which authentication is made by OAuth token. Nothing so special, the username and password are passed to the /auth endpoint and the request returns the token if the credentials are valid. It's working fine.
Now I have to integrate this credentials to a client system. Once the user is logged to my system, so it should be on the client side (like the "login with Google button). I've been searching and realized I should use SAML for that.
I installed the SimpleSAMLPHP and I'm trying to understand how to set it up as my IDP. Once it's made, I can create SPs for my clients systems.
Question: how to make the SimpleSAML use my existing service for authentication? Which module should I use?
With SimpleSAMLPHP acting as an IdP, you want to have a look at authentication modules. The latter is a component that encapsulates the mechanics of signing into the identity provider. For example, if you were trying to sign in to the IdP with your Facebook account, SimpleSAMLPHP ships a FB authentication module that does this for you.
If your existing service can be supported by one of the SimpleSAMLPHP modules, then you're all set. Else, you need to develop your own module.
I want to connect to Archer using a Domain Account. I have followed the documentation provided by RSA and populate the field of the Acher Control Pannel. But the ADFS Team asked me to give them the Federation Metadata file for Archer.
I found this ticket (How to create federation metadata XML for "Relying Party Trust" and "Claims Provider Trusts" for ADFS 2.0) and tried to use the Federation Utility tools. But I'm asked to select a wcf service ... I don't know which one to use. As anyone an hint on which one to select or on how to make the federation metadata for Archer ?
Thanks in advance
RSA Archer support Single Sign On for Active Directory accounts out of the box without any magic required as long as your Windows Server you are running IIS on is a part of the Active Directory domain. You just need to enable Single Sign On in Archer Control Panel and allow Windows Forms authentication. You may need to enable it as well in web.config file. RSA has a detailed guide on Archer Support community site about how this can be done.
At this point I have two versions how to interpret your question:
Version 1: I think that the question you want to ask is how to connect Windows Web Server to the existing Windows Active Directory domain.
If this is the case then you need to ask this question in the Windows Administration stack exchange community. RSA Archer product has nothing to do with making Windows server trust each other on Active Directory domains.
Version 2: You probably are trying to expose Archer to the external users, so the domain you are trying to establish "federation" with is not the same as your Windows Server domain. In this case your question would make sense.
And in this case I would ask your team to provide you detailed instructions about how to extract required information. Different federation services/products may require different information.
In my past experience I asked to have a call with a federation service administrator and followed his instructions and gathered the info he wanted.
Good luck!
We are trying to federate our application, so that our customers can gain access to our application using their respective corporate identities.
Well, I understand the mechanism of federation process, I’ve been able to setting up ADFS and I’ve modified the code of our application for accepting claims into my lab environment and all work fine.
In the next weeks I’m going to build a federation trust between ADFS and our customer’s product (Ping Identity) and I need your help to understand what kind of information I’ll have to exchange with customer’s IT department to complete that step.
I’ve never been experience with Ping Identity products.
Appreciate any help.
Many Thanks
I am going to make a couple of assumptions about your application, mainly that it is .NET application hosted on IIS. This type of application integrates Windows Identity Foundation (WIF) using tags in the web.config and then reads the authenticated users identity information via the Claims Identity object passed to your application. In this case your application is referred to as the Service Provider (SP).
If your customer is using PingFederate, the integration is straightforward in that a WS-Federation SP Connection would be configured on their server referred to as the Identity Provider (IdP). If your customer is using PingOne, then the integration will be tricky.
The information to exchange for PingFederate is driven by the configuration in the configuration in web.config. You need to configure the thumbprint which is based on the digital signing certificate of the WS-Federation response containing the SAMLv1.1 token. Your customer will be able to provide the thumbprint value. You will also need to configure the federated authentication URL, issuer, and realm, which is the information about PingFederate IdP server. The issuer is the URL for your SP application to redirect to the PingFederate IdP server, along with the realm which equates to the PingFederate SP Connection. Be sure that you configure the audienceUris to be the same value as the realm. The PingFederate administrator will need to know your Service URL endpoint which is your SP application endpoint to receive the WS-Federation response with the SAMLv1.1 token.