Does anyone worked on SCIM implementation at Mainframe technology?
Currently we are about to implement this SCIM approach on mainframe. Our master identity system is IIQ and ACF2 is the target system. Any one please share some thoughts about this implementation:
How to generate the ID tags
How to assign the Ref tags.
What are all the technical details to consider before going for this implementation?
Related
We are using Neo4J, to store the users information who are logging into our website. The Roles, Permissions, Privileges are stored in the Database.
I would like to know if there is a good implementation of RBAC, written in NodeJS with Neo4J as the database.
I could see one for Graph ACL, and nothing much for RBAC : Graph ACL
Any experience in this would be useful for us to proceed further.
There's a pretty well thought out graphgist for access control graphs here: https://neo4j.com/graphgist/06bbc73b-80e9-45fc-a1d6-c0270745ddfb
You'll have to apply the nomenclature of RBAC to what's provided (eg, groups in this graph look a lot like roles.) And the actual nodejs implementation isn't even kind of trivial so I can't be of any help there.
I am working on a project based on group secure information sharing environment. We are developing a web application implementing GSAKMP (Group Secure Association Key Managment protocol). Here is the link to its source code.
http://www.ietf.org/rfc/rfc4535.txt
http://gsakmp.sourceforge.net/
Unfortunately the source code on this link is unavailable. Also related to the web based implementation there is no online help available. I am facing issues on HTTP Based group communication and group join request. Is there any one who can help in this regard. Its a generic call for help But I will discuss this in detail with the concerned person. Need a direction.
What Cross-Domain Single Sign-On implementation best solves my problem?
I have two domains (xy.com & yz.com) which already have their own database of users and are already implementing their user authentications separately. Recently there has been the need to implement CDSSO so that users dont have to log in each time they try to access resources from both domains.
Ideally the CDSSO implementation I hope to use should allow custom implementation of authentication, as I hope to call API's provided by both domains during authentication to confirm a user exists in at least one of the domains user database.
I've been looking at Sun's OpenSSO which seems to provide a means to extend its AMLoginModule class yet this seems to be a long thing and more annoyingly they seem to stick to GlassFish.
I've also considered developing a custom CDSSO to solve our needs. Is this advisable?
Is this achievable using Suns OpenSSO considering the disparate user database as I there will be no need to make use of the User db that OpenSSO requires?
Are there any simpler means of achieving what I intend to achieve?
In addition both applications which exist on the two domains were developed using PHP. How does this have an effect considering Suns OpenSSO is based on Java EE?
Are there any clearly specified steps on implementing OpenSSO and or any other SSO implementations from start to finish?
I suggest you to use simpleSAMLphp in order to deploy an Identity Provider and 2 Service Provider (for each app).
SimpleSAMLphp allows you to select multiple authentication source and is not hard to build your own authsource that consults the 2 databases.
My experience in SAML says that the fact of not consolidating the Identity of the user in 1 unique authsource is a bad idea due several reasons:
* identity conflicts: what happen if you have the same user registered with different mail (if that is the field yoy use to identify the user) and you try to access? You could be logged in different account each time.
* what happen if you add a 3rd service, do you gonna add a 3rd database
* what happen if user change its data in one app, the other gonna be no synched?
* what happen if user uses different passwords?
I recommend you to execute a migration process before adding the SAML support and build a unique database for all your identities and unify the registration/edit profile/password recovery process of both sites in one.
SimpleSAMLphp has good documentation, but I can provide to you any documentation related to the process that I suggested.
I'm trying to get my head around SSO concepts and how they fit to my situation, and I've got to the point where I'm a bit stuck. Assuming we use something like Azure AD, or Ping Identity or something along those lines, we want to enable social login (google account / facebook etc) - that is all fine. The bit I keep getting stuck on is how do I control the claims to attach to that identity?
Process (in my head) overview:
- User logs in with google (facebook etc) account, they associate the google account with their 'legacy' account (i.e. link up their social login with their internal identifier that we as a business identify them as) what what ever that process is, does not matter for this discussion (i dont think).
Now when a user logs in with their social account, how do I perform the lookup of that mapping to their internal identifier to add it as a claim, and add the related other claim for that user based on information my organisation knows about them (e.g. If they are over 21, what 'level' of a member they are etc).
I get that if we had one RP using SSO, it as the RP could perform this logic, but we have the situation where we have several internal (and potentially externally managed) systems (4-5 currently) we want to tie together using SSO - which will rely on these claims for access / personalisation etc.
The closest I have seen to this is the concept of a RP-STS - which would effectively from what I could work out sit in front of Ping / AZ AD to form part of the chain, so so it can do the internal lookup and add additional claims as necessary - does that make sense as a concept? Is that the right approach?
I'm sure this can't be un-common - but i can't seem to find any good example / documentation around the full integration (plenty on just AZ AD / Ping etc) that we need. There must be off the shelf products that can do this? (We really dont want custom SSO implementation / components if possible)
The closest I have seen to this is the concept of a RP-STS - which
would effectively from what I could work out sit in front of Ping / AZ
AD to form part of the chain, so so it can do the internal lookup and
add additional claims as necessary - does that make sense as a
concept? Is that the right approach?
That is exactly the role of an RP-STS (or "Federation Provider" in some of the literature). It sits in between your apps and multiple "Identity Providers" and is usually responsible for 2 things:
Protocol transition (e.g. your app might be WS-Fed or SAML, but Facebook is OAuth2)
Claims transformation and enrichment (e.g. add, remove, transform claims based on some logic).
There are several implementations of this with various degrees of sophistication/flexibility, and trade-offs:
Azure Access Control Service can do #1 and (somewhat limited) #2. But it is unclear whether the service has any future or if it will be subsumed by Azure AD.
IdentityServer can do all. It is OSS so you "own" it (e.g. host, operate, customize, etc). It's a great implementation, used in production, written by experts (Dominick Baier & Brock Allen) and very flexible.
ADFS can do some (limited # of protocols, proprietary claim transformation language that is complex to debug, but works). You have to host ADFS yourself. This is a MSFT product.
The company I work for offers similar capabilities too.
I am developing an integration with REST Api with yodlee, and I am worry about security considerations, and would like to hear about the best practices concerning security with the server that talks with yodlee via REST API.
There is a method that returns the users password in plain text, getLoginFormCredentialsForItem()
This worries me a lot and I see that I have to isolate this server with the application server.
Do you have any recommendation to confront this scenario?
Thanks for your feedback on this. I've reviewed this with our Yodlee Security team and they've provided the following response:
The Yodlee Platform stores consumer credentials in a reversible format so that we can use those credentials on behalf of, and as authorized by, the consumer in order to retrieve their data for use by the application. Yodlee has enacted multiple layered security controls as defined by US banking regulations, industry standards (e.g. ISO2700K, PCI) and good industry practices to protect these credentials and the data retrieved by them. When Yodlee deploys with a client, access to the APIs are restricted via network and API level access control lists to complement our and our client’s security controls. However, in this Developer Portal, all APIs are white-listed so that developers can explore the full feature set of the Platform.
We're a longstanding platform with over 10+ years of security and bank-level data audits under our belt and we do not take these or any security concerns lightly. As part of our audit process, we will review the need and use of this particular API and make the appropriate determination whether to modify or remove this API completely from use. We thank you for bringing this concern to our attention.