I am using ADFS as SAML IdP for Gigya. I have setup the integration in both ways, SAML Login is working fine and able to create an account in Gigya. How do I save the Groups in Gigya as Arrays? I am getting AD groups as array in the SAML response from ADFS. I have tried adding the groups by setting Attribute Map as Gigya field as array as described under Gigya documentation but it is not setting the group info in Gigya!
Any help is higlhy appreciated.
The attribute mapping in Gigya's console must be into the "samlData" object (of the profile), like so:
IdP Attribute Name: some-name (as written in the saml xml response)
CDC/Gigya Field Name: samlData.x[] (The brackets are mandatory)
Related
I am trying to implement custom authentication with uses my org's Oauth and gets a token which I would like to pass to my Salt Master of Master. I would want that token to be available in my custom auth module (for the purpose of validating it through my org's APIs). Any idea how can I achieve it.
I have followed below documentation already:
Salt RestCherryPY
I am trying api manager 3.1.0. In one of my API I have defined couple of scopes and added them to the resources.
Example,
Say I have defined two scopes called, add_emp, view_emp(both of them are linked to couple of roles) and added these two scopes for couple of resources like for the first resource /employees linked view_emp and for the second resource /create linked add_emp. And while generating the oauth token cant we generate the token for mulitple scopes, like for the given role he should be able to view employee as well as add employee. But, for the other role only he should be able to view the employee.
While trying this use case. I noticed that, it is not taking multiple scopes. Even though I am passing multiple scopes while generating the token like "scope=add_emp view_emp" the token is getting generated for only add_emp but not for both. But the same use case is working fine on api manager 3.0.0. Is this an issue? or am I doing something wrong.
Please suggest me on this. Thanks in advance.
In order to generate a token with multiple scopes, the user who is requesting the token must have all the roles that are associated with scopes.
Eg:
scope_1 : role_A
scope_2 : role_d, role_e
The user should have either, role_A + role_d or role_A + role_e in order to get a token with both scopes.
Otherwise, a token with only the scope bound to a particular role will be returned.
Therefore, re-check whether the user has roles that associate with both scopes.
For your information I tried to search for the different links but I didn't find the right answer. The below link looks like the same problem but there is no proper answer for this
Artifactory: SAML SSO group matching not working
I am facing a problem with respect to artifactory group association with SAML. Tried to follow the process mentioned in the below link but it doesn't work. Any kind of help is much appreciated.
https://jfrog.com/knowledge-base/how-do-i-configure-artifactory-saml-sso-with-adfs/
Our goal is to create the same group in artifactory which is present in ADFS. So that we can give permissions to that repective group in artifactory. But the problem is people are able to login using their domain credentials where as if we provide the permissions to the group it doesn't work as expected.
If you need more clarity I am happy to explain more on this issue.
The ADFS side is handled by other team even they are not sure why it is not working. Is there any bug in artifactory? I have configured SAML with jenkins it works super fine.
I will try to elaborate about the process.
After a login request, the user and it's groups are available for Artifactory in the assertion response that is sent back to Artifactory by the SAML Identity Provider. The data should be available in the assertion XML response, as long as the Identity Provider configured to include it. For example, the Identify Provider can exclude the groups information and include user data (i.e. username, mail) only.
In order to ensure that Artifactory can assign the user to the SAML a group, you will need to do the following:
Configure the ADFS to include the user groups attributes on login response. You have mentioned that this is handled by other team, but you can see how this can be done in the link that you have attached in your post.
Create the relevant groups in Artifactory, or import them to Artifactory from another authentication provider (such as Artifactory LDAP integration group screen). It is mandatory that there relevant groups will be existed in Artifactory.
Open the Artifactory Web-UI SAML configuration screen, mark the Auto Associate groups checkbox
Edit the Group Attribute textfield, and put the SAML attribute name of the group declaration. The group attribute name that required is the one that is returned in the SAML assertion response.
In the assertion it should look like this:
<saml:AttributeStatement>
<saml:Attribute Name="memberof">
<saml:AttributeValue>group1</saml:AttributeValue>
<saml:AttributeValue>group2</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
In your case, you can either get the group association attribute name from the other team that managed your ADFS as you have mentioned, or just view the assertion in any kind of SAML tracer browser plugin (as long as the ADFS was configured to send the groups attributes)
Once you have the above configured, when a SAML user will log in into Artifactory, the user will automatically be associated to the group that returned by the SAML assertion response (as long as the group exists in Artifactory)
Note: the SAML groups association is not persisted and valid for the current login session only, therefore, if you will edit the user/group screen in the UI, will not that the user/group association, however, if you grant a permission for a specific resource to the group that you expect the user to be assigned to, you can see that the user who logged in is capable of using the granted permission.
I have the ability to login via Facebook and Google on my website. This is done using OAuth2.
I use the same redirect URL whether the user is returning from facebook or google, and pass through the provider name in the state field. Is this the recommended way to track the provider? Otherwise I do not know who to validate the token with if I do not know which provider the token comes from.
Are there other preferred methods for accomplishing this?
The state parameter should be an opaque value that cannot be guessed by an attacker since it is not protected from modifications. If you need to track state, you should refer to it by using the state parameter but that parameter itself should be randomized and/or encrypted. Storing the provider identifier in plaintext in the state parameter is not safe. Users could modify the state parameter themselves or attackers could craft an authorization request with a state value that they choose.
The way to track the provider is by storing it in the backend session state and generate a reference to that session/state that you pass in the state parameter. To prevent cross-site request forgery you should also keep some encrypted/randomized cookie that binds the state to the browser. This is described in more detail: https://www.rfc-editor.org/rfc/rfc6749#section-10.12
Addendum:
One of the problems with using OAuth 2.0 + provider specific extensions for login is exactly this: you cannot establish the provider and user identity in a way that works for all providers in a uniform and generic way. In your case you'll already have to know the provider before you can perform a sensible interaction with it. Enter OpenID Connect: it is a extension profile of OAuth 2.0 that gives you login semantics in a standardized way. It would give you a verifiable JSON object (JWT) with standardized values that tell you who the provider is (iss) and who the user is (sub).
Google signin already has migrated already to OpenID Connect, as has Microsoft and others like Salesforce, hopefully Facebook will follow.
I have implemented ASP.NET Identity 2.0.1 and I am using two-factor authentication for web based sign-ins and I am quite pleased with its usage and overall security.
However for mobile based devices which access the same web sites via the WebAPI 2, I am using OAuth2 Bearer Token authentication and of course there is no such concept as two-factor authentication with bearer token.
What is the recommended approach when one wants the same two-factor level of security on mobile devices as with web based sign-ins ? Am I missing something ?
I've done it this way
User requests token (through OAuthAuthorizationServerProvider) without Two Factor Code - gets back access token with basic claim.
User requests two factor code through post on another controller using this token. This controller method is protected by a claims check (checking the basic claim)
User receives two factor code
User requests new access token through the same token end point (passing the code is as query parameter).
http://localhost:12345/api/token?code=abc
body: {grant_type=password&username=username&password=password1}
In OAuthAuthorizationServerProvider - You need to override GrantResourceOwnerCredentials and check for two factor code - if code is present and user creds are OK - Issue a new token with higher claim which permits access to other resources.