The roadmap for OpenSSO said entitlements would be out summer09. Anyone know whether it will be able to solve data level security, for example "userA can only enter <500 in this field on the screen" OR "UserA can see only these values in the dropdown".
How is this implemented in organisations, each app controls the data level security or is there some who have an enterprise repository for it.
Thanks
yes, this is exactly the kind of problem that OpenSSO Entitlements are designed to solve. I did a demo at JavaOne last week that showed a demo mobile phone account management system with three policies:
Each phone user can read their own permissions (e.g. can download music/video) and call log.
The account holder can read and write the permissions of all phones on the account, and can see the call logs for all phones on the account.
The account holder can read and write account-wide data (e.g. billing address).
I'll be posting the source code to the demo and explaining how to deploy it on my blog.
To answer the second part of your question, there is an enterprise repository for policy, but it is enforced on an app-by-app basis. In the demo, most enforcement is done by a servlet filter which makes entitlement calls for each requested URL. This worked well, since we used RESTful web services that express the requested resource in the URL. In one spot we made an explicit policy call since the URL pattern did not correspond to the policy - the client could navigate to the account resource via the phone URL. I expect I could have constructed another policy to handle this, but I actually wanted to show an explicit entitlement call.
Related
The bounty expires in 4 days. Answers to this question are eligible for a +200 reputation bounty.
Pete is looking for an answer from a reputable source.
I am aware the user impersonation question has already been asked several times.
Unfortunately, none of the questions I read so far provided a reproducible guideline or overall concept how to do this in a secure way. Since every action needs to be logged, I can't use a hack to do this.
For that reason, I would like to kindly ask the community once again for advice and sanity check of my own ideas. Also, new approach suggestions are warmly welcome.
The questions I read so far include:
IdentityServer4 - How to Implement Impersonation
Allow supporter to sign in as another user
Impersonate with IdentityServer, with having an actor claim for the impersonated user
Identityserver3 - User Impersonation
Introduction
Basically, I have an ASP.NET Core Razor Pages app and an ASP.NET Core Web API, both protected by Duende IdentityServer.
Support Engineers need to be able to impersonate customers for service reasons ONLY after the customer consented to impersonation.
Basic work flow:
in the Razor Pages app, the customer activates "Grant Impersonation Permission" under his/her personal settings
impersonation permissions are valid for a maximum of 7 days
customers can revoke impersonation permissions at any time
Support Engineers are then able to log in as any customer that granted impersonation permission at the back office (without the customer being present, no remote-desktop style)
Approach 1:
When the customer grants permission, use the Token Exchange mechanism to exchange for a new access token with a life time of 7 days.
Store this token in a database in IdentityServer and allow only Support Engineers to get a customer's access token via a Controller using the customer's ID, name etc.
While this would work, I'm not comfortable with the idea of storing long-lived access tokens.
Approach 2:
When a Support Engineer logs in, based on his identity, show a custom consent screen where customers can be selected for impersonation and then log in as the selected customer.
The Support Engineer would then get the access token as well as the ID token.
The biggest problem is:
Are there any extension points/mechanisms in IdentityServer to be hooked-in to control the sign-in process to kind of turn the sign-in process to log in the customer instead of the Support Engineer?
Is even possible to do this in IdentityServer?
Approach 3:
In Allow supporter to sign in as another user, user mackie pointed out a high-level view of a impersonation feature.
Here are the steps:
Navigate to client application Sign in using whatever credentials
Check if any impersonation permissions exist (how these are defined is entirely up to you)
Prompt for impersonation account selection (or just continue as self)
Sign in as the selected account (with record of original actor)
Redirect to authorize endpoint
Issue tokens and redirect back to client application
How are steps 4. to 6. done in practice? Any suggestions on that?
I have a question about the problem in your Approach 2. The essence of user impersonation is actually to use "pseudo-token" to impersonate a user to verify some operations or permissions. Or maybe you just want to log all actions performed by the impersonated user?
I think maybe you can intercept on login like in this link. But I think it may be better to add some specific identification to it when the interception is successful, instead of directly using the user's information to log in. I think logging in the customer instead of the Support Engineer might not be a user impersonation anymore (just a personal opinion).
In addition, acr_values is mentioned in the link you provided. From your description, acr_values seems to have some fit:
acr_values allows passing in additional authentication related
information - identityserver special cases the following proprietary
acr_values:
idp:name_of_idp bypasses the login/home realm screen and forwards the
user directly to the selected identity provider (if allowed per client
configuration)
tenant:name_of_tenant can be used to pass a tenant name to the login
UI
For the usage of acr_values, you can refer to this link.
Other link:Impersonation workflow.
This is just my understanding and a suggestion, if I have any understanding wrong, please correct it.
I am trying to implement a hardware busy light to show my Microsoft Teams presence so that my family to not enter the room I have the office while I am in a meeting. I am looking to implement something similar to:
https://www.eliostruyf.com/diy-building-busy-light-show-microsoft-teams-presence
https://blog.jongallant.com/2014/12/beakn-v0-1-diy-lync-status-light/ (older acticle - similar idea).
The only problem I have with this setup is that I cannot get the MS Teams status.
The best way to go is by using MS Graph Presence API but my problem is that this is a company account and I don't have (and there is no way I could have) and app in the main subscription granted with the required scope: Presence.Read.
So I tried different ideas but none worked in the end:
check local running processes
check if MS Teams exposes any local API
check if there is a CLI available
This seems a simple idea, I mean, I see the status right there now while I am typing this message, I could as well do an app that gets a screenshot of the taskbar and extract the status from the icon, but is that really the only option I have?
I think I found something interesting for you.
Go to
C:\Users\user\AppData\Roaming\Microsoft\Teams
you'll find a file called logs.txt
In this file you see if your current state changed
(current state: Available -> DoNotDisturb)
I would write a script with php or VB (depends on your skills) that read that logs.txt file like every minute and check for the last "current state" line.
What those posts are doing (certainly the first one, I didn't check the 2nd one) is calling the Microsoft Graph, which has a "presence" endpoint to get a user's status. There's actually even a specific "/me" endpoint, to get your own personal preference (less access rights needed). See more about this here: https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0&tabs=http
In order for this to work, as you've mentioned, you do need to have an Azure AD App registration. However, importantly, this will only require "delegated" permission (i.e. only permission from the single user, you, to access just data for that single user, you). As a result, you can use "delegated" and not "Application" permissions, which means that it does -not- require Admin consent for the tenant.
It -does- require and Azure Add Application though, at the risk of stating the obvious. While you don't have tenant admin rights, you need to see if you have Azure rights, just to create an application (you might have this anyway as a developer in your org). If you don't even have this, you can sign up for an M365 Developer account, and use that tenant. Importantly - the application does't have to be in the same tenant. If it's not, it's just a simple multi-tenant app, like any 3rd party Azure AD-backed application is.
I have an application where users of my organization, who are not users of this application can register themselves in the first log. When they register, they can choose one or more app's profiles, like contract manager, supervisor etc. These profiles have specific authorization schemes per page, buttons, regions in app. The user must logoff and login again at the inicial log to see these menu's references
Do you know of any way that these menu's references could be viewed/activated in the first of all logs?
The oracle apex version is 5.1.4.
Regards.
I'm answering my own question as follows:
I do a self-criticism for the question because I consider it to have failed to take into account all aspects of information security. Even though I'm always careful about security, a solution of this kind might attend me, considering a IT's well secure work's scenario, but may not be the case for all environments.
I would consider this a valid question for security experts, who could see in the scenario that I proposed, a failure in the APEX environment, in which I have not yet seen.
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?
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.