I installed the ruby on rails plugin "open_id_authentication". After running the migration it created two tables "open_id_authentication_associations" and "open_id_authentication_nonces" does anyone know what those tables do and how they are used?
Thanks
iHeartDucks,
Here is a site that has much more discussion on what exactly is happening with the open_id_authentication plugin, and why it needs these tables. You will find:
These tables, "open_id_authentication_associations" and "open_id_authentication_nonces", store information about the messages received from OpenID identity providers, including authentication keys.
Thanks!
The open_id_authentication_nonces table stores the openid.response_nonce value, which is basically a string starting with a timestamp and ending with a unique value.
The open_id_authentication_associations table stores information like the OpenID server url, username, secret, etc - the information needed for the user to authenticate.
Related
I have a problem with node-oidc-provider.
I want the client list to be stored in the database, but I haven't found a solution.
Please help me!!!
You can have your client definitions stored in a DB, just have your adapter for the Client model respond to the find(id) invocation.
https://github.com/panva/node-oidc-provider/blob/main/docs/README.md#clients
In addition to these clients the provider will use your adapter's find method when a non-static client_id is encountered.
For storing clients in the database, you can make use of below link to store the clients as well as other tokens
https://github.com/panva/node-oidc-provider/blob/main/example/adapters/contributed/sequelize.js
For creating tables, you can use below link
https://github.com/roggervalf/node-oidc-provider/tree/examples/example/migrations/sequelize
I am trying to put together some documentation on changes that need to be made to the Database back-end when different actions are performed so they can operate with IdentityServer4, but realizing that I am not sure what items in the database are affected when you perform actions like (adding a new user, adding a new client, and a scope, etc..) I am using this to get a better understanding of how all the elements work together, and how to relate to each other - See below which I am needing to expand on.
Can anyone with good experience with IdentityServer backend help me?
[Adding a new user]
- add a record to dbo.AspNetUsers – All user pertaining information.
- add a record to dbo.AspNetUserClaims – Identifying information stored similar to Key/Value Pair set with a reference pointing to the User
[Adding a new Client – (Controller Web API Endpoint)]
- add a record to dbo.Clients – Details that define the client
- add a record to dbo.ClientGrantTypes – All grant types allowed for authorization to the specified client.
- add a record to dbo.ClientSecrets – Password and secret information pertaining to the client.
- add a record to dbo.ClientScopes – Scope name matched to the ClientId for allowing. You will need to add scope(s) for the client so it can be accessed.
-?? Not sure how IdentityResoure and IdentityClaims are used here, and also how oidc ones are used here.
?? What is the difference between Api and Client in Identity Server DB?
[New Claim type is added, and needs to be included in the data returned with the JWT token]
...
use IdentityServer4.AspNetIdentity for storing users in SQL Server using EF http://docs.identityserver.io/en/release/quickstarts/6_aspnet_identity.html
use IdentityServer4.EntityFramework for storing clients and resources configuration in SQL Server using EF.
http://docs.identityserver.io/en/release/quickstarts/8_entity_framework.html
Look into the samples repository for code samples.
I'm currently confused by the IDs identifying a user in Connections, and their link to the underlying LDAP directory.
So far, I identified several ids:
email: simple but not reliable as email access might have been disabled by the admin. This is particularly true for Connections cloud.
snx:userid: UUID generated by Connections, but this is the chicken and egg. To find the userid, you need to first get access to a profile document, or some data retrieved from Connections
key: also generated by Connections, but I don't get the pattern. On Greenhouse, it is yet another UUID in x-profile-key, different from the userid above. On other systems, it seems to be based on the user name.
subscriberId: The "lotuslive id" used by Connections cloud.
Can someone explain the relationship between snx:userid, key and subscriberId, on-prem and on the cloud, and what they are for? I can't find any clear documentation around it. The API doc says that some times we should pass the key, and some times the id.
Also is the LDAP directory on prem. We are querying the LDAP directory (WAS federated directory, also used by Connections) to get a list of users based on a group. But then, how can we access their Connections profiles from the LDAP result? Is their an attribute to read? We are currently using the email, but as said earlier, this will not work if email access in disabled, like in Greenhouse.
I can explain part of it. the snx:userid is an abstraction used to uniquely identify a person - even if their email changed, name changed, or any other ldap specific id changed. The snx:userid is I believe 64bit.
I thought the Key is the same as snx:userid.
SubscriberId is based on the Business Support Services long id, and includes a scope so that each environment has a unique id.
I think I described the first part of your question on the relationship.
For the second bit, we don't augment LDAP with the snx:userid.
You may want to look at User SPI and java.lang.String getExtID()
http://www-10.lotus.com/ldd/lcwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Connections+5.0+API+Documentation#action=openDocument&res_title=User_SPI_ic50&content=apicontent
Hopefully this will help clear up some of the confusion and break down their relationships and uses.
snx:userid — This is actually not “generated” by Connections, but rather is associated with an LDAP attribute that is defined during the population process. Generally it is defaulted to an LDAP attribute that is and will always be unique to a user so that it can be used to identify a user in the LDAP if other content has changed. In some cases you’ll see this as the GUID of the LDAP (the default setting on-prem), though other times you’ll see this as a different value, like on the cloud for example. The cloud has this set this to the subscriberId.
subscriberId — This is generated and based on our Business Support Services as Paul mentioned. It is used as the true unique identified for a “subscriber” (user) to the environment, since the environment is MT and users need to be scoped. This was chosen over the default GUID as a unique identifier for a variety of logistical reasons.
key — This is generated by Connections itself during the population process. It is used to define the users profile within the context of Profiles and provides Connections with the ability to associate content with a user when the users LDAP information has been altered. It provides a separation of identity and helps facilitate user content synchronization for Connections.
Unfortunately there isn't a clear cut way to perform that lookup though, especially when you take something like Connections Cloud or Greenhouse into account. They have email disabled for a variety of security reasons. Generally speaking though, the userId is the GUID for the ldap, unless it is very explicitly redefined and configured so, but again you'd really have to know the environment in order to know that information. In a nutshell I think it has to be a configuration parameter for the app per environment if email is disabled.
I have a restful API that is going to accessed by multiple organizations. Their data is going to always be separate. I am using rails 4.0, emberjs, and phonegap. There are going to multiple devices accessing the API for a single organization at any point in time.
My question is how to properly design my API with these multiple organizations and devices in mind.
Current Solution:
The user must authenticate with the organization name and password. This is done over HTTPS with basic auth. After that the user is given a token that ember stores and is used for each subsequent request. Since there are multiple devices multiple API tokens can be associated with an organization. Rails uses the token to get the organization id with every request so the url /members only outputs the members related to the organization the token belows to. Thoughts on this?
Requiring every restful resource to be started with organization/id/resource seemed insecure and unwieldy to me so that is why I chose my current solution.
A Better Way?
What is a better way of doing this? Should I give each organization a subdomain and pass that back along with the token and use the token only for security and the subdomain for identifying the organization? Or should I just stick with organization/id/resource?
You are right, the token itself should not contain any "organization" part - it's insecure, as well as adding subdomain in the way you've proposed.
Instead of that you can add Organization field to the Token object (or table - depends on how you track tokens). Once you received the token you're able to get the Organization.
I'm using Devise in a Rails app and want to expose some of the model data via an API, but access to the API should be restricted just like the app.
$ curl http://myapp.com/api/v1/sales/7.json
{"error":"You need to sign in or sign up before continuing."}
Obviously.
Is there a best practice for accessing the API in situations like this? I'd prefer to authenticate + grab the data in one step, but that's just to make the client's job easier. They'll be pulling in the data client-side with JQuery.
Thanks for any info!
Vanessa
I recommend you follow the Option 2: Using API Key section on the following post to implement API authentication in Rails.
http://www.whatcodecraves.com/articles/2008/11/25/how_to_make_an_api_for_a_rails_app/
It's lightweight and simply requires passing an api_key param with each request.
My suggestion would to generate an API "key" (hash value) and have that passed with the json request. That way you can authenticate and track API use. A lot of APIs use "keys" to track and authenticate use. Google maps for instance, they use just an API key. Where as PayPal uses a user name, password, and key. There are a number of ways to do it.
I would try creating a one-to-many table that belongs to the user, just for keys. That way a user can generate more than one hash key for different purposes. (One for reports, one for backup, one for fancy pie charts that automagically pull from Powerpoint).