I'm trying to get the user's identity from an adapter and I see that the documentation mentions two different APIs that look like having equivalent descriptions to me: getActiveUser and getCurrentUserIdentity.
Looks like the first one needs a realm as a parameter: https://stackoverflow.com/a/17018349/239408. I don't know about the other one.
The documentation also refers to a strong identity concept that I haven't seen described anywhere.
Should I prefer one method over another? When should I expect to have a "strong identity" and not get back a null?
When you have multiple realms, each one of them will have a userId. e.g. realm used for authenticating users will have userIdentity that describes user properties, i.e. username, date of birth, displayName. realm used for authenticating devices will have userIdentity describing device properties, i.e. deviceId, platform, OS version etc.
getActiveUser(realm) will get you a userIdentity of the specified realm. if you do getActiveUser("wl_deviceNoProvisioningRealm") you'll get identity of the device (assuming you are using wl_deviceNoProvisioningRealm).
getCurrentUserIdentity() and getCurrentDeviceIdentity() APIs are built on top of getActiveUser(). You don't have to specify explicitly which realm is used to identify user and which realm is used to identify device, WL server will do this for you and you'll automatically get userIdentity of current user and userIdentity of current device.
Related
We have an existing OAuth2 based website. Our plan is to use a web based (XMPP over websockets) chat system.
now this chat system will be available once the user logs in. What we actually do not want is to login twice, once for the web site and once for the chat system.
So I figured how to trick it with my own auth provider and a custom username/password.
So basically the question is how do I have an object that I want to travel along with the user chat session so that I can provide out of band processing.
Does the session management allow this?
In a similar use-case, there I need to persist and store various pieces of information about a user, in Openfire, so that external calls and look-ups are not necessary during later, custom logic in an Openfire plugin. It is possible to add any number of custom properties to an openfire user, via REST, or other APIs.
Then, those custom properties can be retrieved as needed, without external calls.
create user api
Then, if using Internal APIs, you get
Get the session's username or address (JID)
call UserManager's getUser on the username or JID to get the User object
call User's getPropertyValue to get a specific property or getProperties to retrieve all custom user properties
Maybe I didn't really get the concept but basicly if you say you're compatible with SCIM then there must be certain expectations of properties that belong to identities am I right?
For an example if you take a look at the example createUser request from
https://developers.onelogin.com/scim/implement-scim-api
you will see a variety of different properties like displayName, nickName etc..
My use case however requires only one name, the userName.
My question is, are any of these even required to say that you are SCIM compliant?
The RFC7643 indicates that the id parameter must be included.
The requirement for the other properties depends on the resource type and thus schemas used by your application. For a user resource, the section 4.1 of the RFC indicates that the userName is also required.
I'm looking at the AspNetIdentity_2fa sample and trying to modify it to include some dynamic claims for users. Let's name it calculated_value claim which is created dynamically when a user is authenticated, and then is included in the user's claims list and passed with the the authentication token. I know I could create a separate Web API to get this value but since it is small data and that it is needed as soon as a user is authenticated, I thought I'd just pass it as claim. In the samples I see that claims always coming from static or hard-coded data. How can I create dynamic/late-bound claims?
Thanks!
Some time ago I spent some time on trying to integrate Identity Server v3 with Active Directory. I wanted to authenticate users via AD and to read "claims" from AD. To do so I provided a custom implementation of IUserService. It was more or less based on in memory implementation of these interface i.e. InMemoryUserService.
When your custom implementation is ready you have to register it. However, AspNetIdentity_2fa sample project already registers a custom implementation of IUserService i.e. UserService (just search a project for this class). It is derived from AspNetIdentityUserService which implements IUserService.
So, instead of providing completely new implementation try to modify it. I think that you should look at AuthenticateLocalAsync, AuthenticateExternalAsync and GetProfileDataAsync methods (see InMemoryUserService for reference) and override them. First 2 are used to authenticate users and the last one to read requested claims for users.
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.
The processing sequence could look like the following:
Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
Validate user with username, password and user type (from relying party configuration)
Add claims depending on user type or relying party specific configuration.
The datasbase/class structure for this could look similiar to this:
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
#Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.
I'm reading about Federated Login for Google Account Users to figure out how I can have a user log in to a web application using their Google Account.
So towards the end of the process, Google returns a Google supplied identifier which is appended as openid.claimed_id. This means the web application uses this identifier to recognize the user and allow access to application features and data. My question is, is this identifier static? Can I use this identifier to repeatedly id the same user?
Yes. Consider the openid.claimed_id value to be the username. Especially with Google, but this is true for any OpenID Provider that truly implements 'directed identity', don't consider this username to be correlatible with other web sites. Any other relying party besides your own web site will get a different claimed_id value for the same Google user, by design.
Also, be sure to treat this claimed_id as case sensitive.
The specific answer to your question is found in Googles OpenID API documentation:
The Google-supplied identifier, which has no connection to the user's actual Google account name or password, is a persistent value; it remains constant even if the user changes their Google user name and/or email address. This identifier is also a "directed identity", that is, Google returns a different value to each relying party. Google uses the request parameter openid.realm to recognize the relying party, so if the third-party application decides to change this value, all user identifiers will change.
In fact, I just ran into an instance where the google claimed_id had changed for my test user. I was coming to the end of implementing OpenID into my app, and for no apparently reason the claimed_id in the response data is had changed.
I've been testing with this account for the past couple weeks, and the claimed_id was the same this entire time, as expected. Then wham, changed! I looked at the response data many times to verify, and the underlying code to retrieve the data had not changed.
I'm not sure how to handle this at the moment, but I think this is going to throw me for a loop. After initial authentication, users register to the site (as you might expect) and setup a screen name. How are we to verify it is the same user if the claimed_id had changed? We certainly can't use email address, per best practices.
EDIT
Now I have pie in my face! I missed one little detail, that turned out to be a major detail. I change my development environment and was hosting on a different v-host. This effectively change the realm, and this will change the claimed_id response according to the docs.
This was a good lesson for me, as I was about to implement OID on a subdomain in which realm was being set automatically in my code. Now I saved myself a headache down the road, because I would not have been able to use the same user database across all other sub-domains without breaking identity.
updating realm
MORE INFO
Just as a side note - even if you are developing your OpenID solution for one of your subdomains, it might be prudent for you to specify realm to your top-level domain.
e.g., openid.realm = http://*.yourdomain.com
It will allow you to expand your sign-in page across all your subdomains and keep user identity across them.
(optional) Authenticated realm. Identifies the domain that the end
user is being asked to trust. (Example: "http://*.myexamplesite.com")
This value must be consistent with the domain defined in
openid.return_to. If this parameter is not defined, Google will use
the URL referenced in openid.return_to.