I was told that Tableau server requires these 2 SingleLogoutService elements below that are not in the SAML metadata from Azure AD. If I add these, it works.
Is it supported to manually add these?
Is there a plan to add these in the future to the metadata on AAD?
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/f4094948-32fb-4c4b-b659-63b99f22a08d/saml2" />
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://login.microsoftonline.com/f4094948-32fb-4c4b-b659-63b99f22a08d/saml2" />
WE never heard this as a requirement from the Tableau side. Can you please specify that you are using Tableau server or cloud version? If this is server then which version of it?
You can add more Logout URLs int he metadata as you need but note that Azure AD does not support SOAP biding or Redirect binding for SAML Logout. Only POST biding is supported.
Related
I'm using Symfony 4(.4.11) and trying to implement a LDAP Authentication, while the User Properties (Username and Roles) are stored in a DB. Thus I added a User Entity for Doctrine and configurated the services.yml and security.yml corresponding to the Documentation.
I also used the Maker Bundle to generate a LoginFormAuthenticator which seems to use the Guard Authenticator Module.
When I'm trying to login it simply looks like it is not doing anything LDAP related. I also listened the TCP packages with tcpdump and didn't see any traffic to the LDAP server.
I have read (and re-read) the security docs but this in particular:
https://symfony.com/doc/current/security/ldap.html
that said :
The http_basic_ldap authentication provider, for authenticating against an LDAP server using HTTP Basic. Like all other authentication providers, it can be used with any user provider.
Sounds like it should be possible but I haven't been able to figure out how to wire this in security.yaml and services.yaml
Currently, I can connect very well with the http_basic_ldap but how to match the username with the one in DB in order to get its roles?
Thoughts?
I am trying to setup SSO for PSM application as per this link - https://www.ibm.com/support/knowledgecenter/en/SSL5ES_2.3.2.0/intel/iwd/aat_sec_sso.html
It says I should - upload the IdP metadata XML file received from the Identity Provider.
The Identity provider available in-house is Active Directory.
How to get the metadata XML for Active Directory ?
I am unable to find it .
Thanks,
ADFS does not provide SAML IdP meta data alone, but Federation meta data. Typically you can get it from https://FQDN_OF_THE_ADFS_SERVER/FederationMetadata/2007-06/FederationMetadata.xml
Then you need to extract the SAML IdP meta data from it. Alternatively you may reach out to the ADFS admnistrator and request it. Judging from my experience, you mostly also get the Federation meta data, instead of the SAML one.
I have an application running on B2C as part of customer deployment we federate with the customers AD so they can log in with their own corporate identity.
We then create matching groups in the B2C to control behaviors in the app.
We have a request that a customer wants to create the groups in their AD and then pass it across so that they can manage their users and access in one place.
I can see how I can add the claims I want when setting up a user flow but I cant see any option for groups. Is it possible to do or do i have to query the external AD (matching the way I query for groups in the B2C directory)
Thanks
While technically possible, I still have question for the benefit of doing this.
I will try to briefly describe how this would technically work. If not clear - I will have to summ-it on Github. This is only possible using custom policy. So you have to follow: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-technical-profile
Edit the Menifest of the application registration in federated AAD. There you have to indicate that you require group membership claim:
"groupMembershipClaims": "All",
Extend the claims schema in your custom policy extensions by adding a new claim:
<ClaimsSchema>
<ClaimType Id="idpGroupMemberships">
<DisplayName>Group Memberships in the IdP</DisplayName>
<DataType>stringCollection</DataType>
<UserHelpText>This is read only for the user</UserHelpText>
</ClaimType>
</ClaimsSchema>
Later in the technical profile, copy the incoming groups claim into your outputclaims:
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="idpGroupMemberships" PartnerClaimType="groups" />
</OutputClaims>
Finally, you have to include that new claim in your relying party policy:
<RelyingParty>
<DefaultUserJourney ReferenceId="SuSiLocalFbStaykovNet" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="idpGroupMemberships" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Using this approach you will get the Groups as GUIDs (these will be the objec IDs of the groups in federated AAD). If you want to get the Groups as names and not GUIDs, it is only partially supported and more complicated. Check out this doc here: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims#configure-the-azure-ad-application-registration-for-group-attributes
Not exactly an answer but some insight why this might be useful.
While technically possible, I still have question for the benefit of doing this.
I have a smaller organization and a public facing B2C offer and a management UI that handles the customer requests. Some sensitive data is on an internal SQL server and we have for historical reasons and some elder software an on-premise AD. I have now running AAD B2B with hybrid connection and SQL via hybrid connection. Customers running on B2C. Because it's technically just one app, it's also just one login --> ADB2C with a social IDP pointing to AADB2B, that internally is backed by the on-premise AAD.
That all works very well and is exactly what we need. I came here with the same question as the OP to forward the security group information to the token to handle some access restrictions in the management UI.
Hence, for me the scenario makes absolutely sense. Just my 2 cent.
I am managing an SAML2 enabled idP, and now I need to import an SP into the idP server.
Usually I will just download the xml from the SP, and import it into our idP.
However, I was reading a documentation which said it is possible to just use HTTP(s) to load the metadata to our idP. (https://docs.spring.io/spring-security-saml/docs/1.0.0.RELEASE/reference/html/configuration-metadata.html#configuration-metadata-idp-http)
Which seems more convenient (no need to manually re-cert), but I am concerning whether this will lower our security.
So my question is, is it safe to load SP/idP metadata by URL? If so, any reason behind it? Thanks!
how you get it is secondary to how you validate it. The metadata should be signed by the issuer and your IdP, when it automatically downloads it, should verify the signature on it. A lot of IdPs use the UK Federation metadata url to automatically ingest/update SP metadata. The metadata is signed by the federation so the IdPs can verify its integrity.
I am just getting started with SAML. AFAIK, in the authentication step, there is no direct communication between the IdP and the SP and the assertion happens via the browser.
In my applications (which will be the SP), I would like to store some user specific data (stuff like page size, other UI preferences). When the user is deleted from the IdP, I would like to purge this data from my application as well ? Is it possible to get this "event" from the IdP to the SP for such tasks ?
PS - My app is PHP based and I am likely to simplesamlphp.
Thanks,
~preetham
There is no support in the SAML 2.0 spec for having the Identity Provider call out to the Service Provider for events related to user provisioning or deactivation.
However, there is a SAML protocol called SubjectQuery and a request called NameIDMappingRequest which might serve the purpose if you had a nightly batch job or something that would query users which haven't logged on in x days to see if they still exist on the Idp.
You can find the details on these in the Profiles Section of the SAML spec but I don't know what support (if any) simplesamlphp has for these profiles.