Specify "aud" for OneLogin JWT - onelogin

I'm adding OneLogin SSO support into our Android and iOS apps via OpenId Connect.
It's all working OK except that I can't find a way to configure the "aud" field of the JWT.
OneLogin is just putting some sort of GUID in this field, but our API requires a very specific audience value.
For other IDP's, like Azure Active Directory and Okta, this has been possible.
Does anyone know how to configure OneLogin OpenId Connect connector to specify an audience?

You can't configure the 'aud' value in Onelogin. Appreciate you can set it in Okta, but OL sets it as a GUID.

Related

How can I set the SubjectConfirmation ConfirmationMethod with the Azure AD B2C SAML IDP?

I am using Azure AD B2C as a SAML IDP to achieve SSO. The service provider has a requirement to set the SubjectConfirmation ConfirmationMethod in the SAML token to 'sender-vouches' as follows:
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
By default, when I issue a SAML token, the ConfirmationMethod gets set to 'urn:oasis:names:tc:SAML:2.0:cm:bearer'.
I am using an Identity Experience Framework custom policy.
I have researched the B2C documentation extensively to figure how to manipulate this value but I haven't found any feature that allows it.
Is it possible to modify this value and where in the XML would I do it? I assume, if it is possible, this would be done in the SAML token issuer technical profile. This page describes that but there are very limited config options:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-issuer-technical-profile
There is some discussion about SubjectConfirmation in configuring an external IDP but that is not my scenario:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-identity-provider-technical-profile
There is an option to set SubjectNamingInfo in the relying party config which sets the name ID format but no option for subject confirmation method:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/relyingparty
Thanks in advance.

Azure AD OIDC changing preferred_username format

I've set up a Registered App for OIDC and configured it for various usages on Azure AD.
The application I integrate with uses preferred_username in the ID Token for various things. Azure AD assigns username#company.com, a.k.a. UPN to this field. I'd like it to assign username which could be the good old SamAccountName or UPN transformed in some way.
Is there any way to do this?
This seems to be possible for SAML (NameId is kind of equivalent to preferred_hostname on OIDC the way I see it) but I couldn't find anything relevant for OIDC. https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization#editing-nameid
I've tried changing manifest file in the app with some educated guess but did not managed to accomplish this. I could not find anything related in manifest documentation.
The ID token is the core extension that OpenID Connect makes to OAuth 2.0. ID tokens are issued by the authorization server and contain claims that carry information about the user.
OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that you can use to securely sign in a user to an application
These are list of claim for ID token you can configure before generating a token
AzureAD-ADApplication->Token Configuration-> Add an optional claim.
There you can able see list of claim including UPN as well.
Claim for samaAccount only under group claim.

Docusign- RestAPI and how to handle clients with SSO enabled

My company (C1) has DocuSign implementation feature set up with RestApi and we use oAuth to authenticate users with email and password to create and send envelopes. This functionality works perfect.
One of our clients said they have SSO enabled in their org and would like to SSO directly to DocuSign from my company page instead of providing password option. In our current implementation, users are prompted for email address first and then the password.
If clients have SSO enabled, I assume they go directly to Docusign but to get that functionality, is there anything I need to do regarding changing the existing workflow or implementation for RestAPI.
Do we need to obtain consent for our Client (who has SSO enabled)?
Thanks in advance
You don't need to do anything differently. These clients would be able to authenticate to your integration/app using SSO. If they are already autneticated, a cookie remembers it and they would automatically be redirected back to your app. The first time, the would have to give consent to your app to enable it to do things for them, but after that - smooth sailing, without any need to login or anything.
Feel free to let me know if you run into any issues. Otherwise, you'r good.
As Inbar says, if your application uses either the OAuth Authorization Code or OAuth Implicit grant flow, then your application will automatically support SSO once the user's DocuSign account has been set for SSO.
If your application uses the OAuth JWT grant, then SSO has no bearing on your application since your application is itself authenticating with DocuSign and impersonating a user.
And the above is why Authorization Code grant or Implicit grant is preferred over JWT grant whenever there's an option to not use JWT grant.
If you're using Legacy Header authentication, your application won't be able to authenticate as users who have SSO Login enforced. Until you're able to implement one of the OAuth workflows, users who need to use your API integration will need to have their Login Policy set to allow them to login with a password. More info on Login Policy is available here: https://support.docusign.com/en/articles/How-to-exclude-specific-users-from-SSO-requirements

Using SAML to retrieve a list of users from an idp

Given a service like Okta, is it possible to use raw SAML requests to get a list of users from my Okta domain? We are hoping to use SAML to retrieve users from Okta and generate linked accounts based on those Okta users for them to sign in to our system using SSO, but we need user accounts in our system that are linked to Okta accounts, or any other SSO/SAML/idp provider.
You cannot do that with SAML. SAML allow user to access other applications from the IDp.
You will need to use their API and authenticate using Oauth, no SAML.
https://developer.okta.com/docs/api/resources/users.html.
What about using Just in time user provisioning based on SAML assertion attributes?
SAML is an Authentication/Authorization protocol, not a user management protocol.
If you're using OneLogin, check out their APIs: https://developers.onelogin.com/api-docs/1/users/get-users

Expose Values of Extensions via SAML 2.0 Using Azure Active Directory as Identity Provider

I am trying to configure SP-initiated SSO using SAML 2.0 between Azure Active Directory and NetSuite OpenAir. OpenAir requests a company ID and a user ID that are not part of the Azure Active Directory schema, so I added the necessary fields as extensions using the method at http://blogs.msdn.com/b/aadgraphteam/archive/2014/03/06/extend-azure-active-directory-schema-using-graph-api-preview.aspx
I now have the extension fields populated in AAD (one for UserID and one for CompanyID) but I do not know how to edit the Federation Metadata to enable them to be requested and asserted via SAML 2.0. I also don't know what URI to use to get the actual value included in the response.
This is the solution I've chosen for SP-initiated SSO with AAD as IdP, if you have another suggestion please let me know. I've been looking here, on MSDN, and on various documentation sites and blogs without success for about a week.

Resources